Marvell SATA Controller. Problem booting and detecting HDDs in kernel 3.2.0.

[VB Wright]

While HDDs conected to my SB950 controller are detected, ones connected to the Marvell 88SE9172 Controller are not, also causing a significant delay in boot times. This was also present previously when when I used kernel 3.0.0 in LinuxMint 12. The affected drives are still able to be booted from and recognized within Windows 7.

## dmesg results for delayed period:
[ 6.908078] ata9: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 6.908948] ata9.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
[ 12.392060] ata10: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[ 12.393795] ata10.00: failed to IDENTIFY (device reports invalid type, err_mask=0x0)
[ 17.392075] ata9: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 17.392958] ata9.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
[ 17.392962] ata9: limiting SATA link speed to 1.5 Gbps
[ 22.876062] ata10: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[ 22.884055] ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[ 22.884926] ata9.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
[ 28.376054] ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310)

I'm having a similar issue to bug #260543, "JMicron SATA Controller. Problem booting with kernel 2.6.24-19. Boots fine with kernel 2.6.22-14" [ https://bugs.launchpad.net/ubuntu/+source/linux/+bug/260543 ].

WORKAROUND: Disabled IOMMU in the BIOS.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: linux-image-3.2.0-23-generic 3.2.0-23.36
ProcVersionSignature: Ubuntu 3.2.0-23.36-generic 3.2.14
Uname: Linux 3.2.0-23-generic x86_64
NonfreeKernelModules: fglrx
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
ApportVersion: 2.0.1-0ubuntu7
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: blairfus 1818 F.... pulseaudio
 /dev/snd/controlC0: blairfus 1818 F.... pulseaudio
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found.
Card0.Amixer.info:
 Card hw:0 'SB'/'HDA ATI SB at 0xfdff4000 irq 16'
   Mixer name : 'Realtek ALC889'
   Components : 'HDA:10ec0889,1458a132,00100004'
   Controls : 46
   Simple ctrls : 22
Card1.Amixer.info:
 Card hw:1 'Generic'/'HD-Audio Generic at 0xfddfc000 irq 46'
   Mixer name : 'ATI R6xx HDMI'
   Components : 'HDA:1002aa01,00aa0100,00100200'
   Controls : 6
   Simple ctrls : 1
Card1.Amixer.values:
 Simple mixer control 'IEC958',0
   Capabilities: pswitch pswitch-joined penum
   Playback channels: Mono
   Mono: Playback [on]
Date: Sun May 27 12:49:54 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425)
IwConfig:
 lo no wireless extensions.

 eth0 no wireless extensions.
MachineType: Gigabyte Technology Co., Ltd. GA-990FXA-UD5
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 VESA VGA
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-23-generic root=UUID=487183dc-39a8-473b-9ccd-b61dae790470 ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.2.0-23-generic N/A
 linux-backports-modules-3.2.0-23-generic N/A
 linux-firmware 1.79
RfKill:

SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 03/30/2012
dmi.bios.vendor: Award Software International, Inc.
dmi.bios.version: F7
dmi.board.name: GA-990FXA-UD5
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.chassis.type: 3
dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrF7:bd03/30/2012:svnGigabyteTechnologyCo.,Ltd.:pnGA-990FXA-UD5:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnGA-990FXA-UD5:rvr:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr:
dmi.product.name: GA-990FXA-UD5
dmi.sys.vendor: Gigabyte Technology Co., Ltd.

[VB Wright (vbwright)]

Here is a copy of dmesg with IOMMU disabled, no other changes.

[madbiologist (me-again)]

This device appears to have more than one PCI ID. Support for 1b4b:917a was added in the upstream kernel 3.4, and is under review for 3.3 and 3.2 updates, but according to your Lspci.txt file you have 1b4b:9172

See http://theangryangel.co.uk/blog/marvell-88se9172-sata3-under-linux-as-of-320 for info on how to add support manually under kernel 3.2. Note that they have a third PCI ID - make sure you use yours.

Here is the 3.4 kernel patch for reference:

author Matt Johnson
Fri, 27 Apr 2012 06:42:30 +0000 (01:42 -0500)
committer Jeff Garzik
Thu, 3 May 2012 18:07:40 +0000 (14:07 -0400)
commit 642d89252201c4155fc3946bf9cdea409e5d263e
tree f6287317640b23fe34233e4227cb07585f73e471
parent 6868225e3e92399068be9a5f1635752d91012ad5

ahci: Detect Marvell 88SE9172 SATA controller

The Marvell 88SE9172 SATA controller (PCI ID 1b4b 917a) already worked
once it was detected, but was missing an ahci_pci_tbl entry.

Boot tested on a Gigabyte Z68X-UD3H-B3 motherboard.

Signed-off-by: Matt Johnson
Signed-off-by: Jeff Garzik

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.4kernel[1] (Not a kernel in the daily directory). Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag(Only that one tag, please leave the other tags). This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-quantal/

[VB Wright (vbwright)]

Yes, I'll do that this week. Are there any logs I should submit as well?

On 05/29/2012 06:22 PM, Joseph Salisbury wrote:
> Would it be possible for you to test the latest upstream kernel? Refer
> to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest
> v3.4kernel[1] (Not a kernel in the daily directory). Once you've tested
> the upstream kernel, please remove the 'needs-upstream-testing' tag(Only
> that one tag, please leave the other tags). This can be done by clicking
> on the yellow pencil icon next to the tag located at the bottom of the
> bug description and deleting the 'needs-upstream-testing' text.
>
> If this bug is fixed in the mainline kernel, please add the following
> tag 'kernel-fixed-upstream'.
>
> If the mainline kernel does not fix this bug, please add the tag:
> 'kernel-bug-exists-upstream'.
>
> If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
> Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".
>
>
> Thanks in advance.
>
> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-quantal/
>
> ** Changed in: linux (Ubuntu)
> Importance: Undecided => Medium
>
> ** Tags added: kernel-da-key
>
> ** Tags added: needs-upstream-testing
>

[blinko (55-glitteranddoom)]

I've just tried the 3.4-quantal kernel [ http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-quantal/linux-image-3.4.0-030400-generic_3.4.0-030400.201205221131_amd64.deb ], and the issue persists that devices attached to the Marvell controller fail to be recognized with IOMMU enabled. Removing tag 'needs-upstream-testing', and marking as 'kernel-bug-exists-upstream', as requested.

[VB Wright (vbwright)]

Used my casual login above (blinko), sorry for the spam and any confusion.

Re: madbiologist (>>#3)
Using kernel 3.2, I've added '/bin/echo 1b4b 9172 > /sys/bus/pci/drivers/ahci/new_id' to my rc.local and have run it separately, but without effect. Assuming the patch you listed was applied to the 3.4 kernel I tried, is there anything else to do?

[madbiologist (me-again)]

Hmm, I'm not sure why that command doesn't help.

As for the 3.4-qantal kernel, it should have the patch that I listed, but it won't help you as it specifies a different PCI ID (1b4b:917a). I just listed it in case someone else who has a controller with that PCI ID comes across this bug.

You could try emailing Matt Johnson, the author of the patch I listed, to see if he can supply another patch with your PCI ID. To stop SPAMbots, I removed his email address from the patch I listed but you can find it in the changelog at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=log;h=refs/tags/v3.4-rc6 - Just search that page for his name.

[madbiologist (me-again)]

The patch described in comment #3 is now also included in the upstream kernel 3.2.19 - commit 521045df1e89da82494e8cfbddb74ab169c7b5d0

[penalvch (penalvch)]

VB Wright, could you please test the newest mainline kernel available http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.5-rc1-quantal/ ?

[VB Wright (vbwright)]

Christopher, I'll try it now. Also, I've just switched from Ubuntu 12.04 amd64 to Linux Mint 13 MATE amd64, so I'm unable to file using ubuntu-bug. However, if there's any other information I could provide manually, I'd be happy to do so.

[VB Wright (vbwright)]

The issue persists with kernel 3.5-rc1-quantal. HDDs attached to the Marvell controller were only recognized when IOMMU was disabled.

[penalvch (penalvch)]

VB Wright, thank you for testing the mainline kernel. If you disable IOMMU in the BIOS, does this problem ever occur in the Precise repo kernel or less frequently?

[VB Wright (vbwright)]

No, all drives have always been detected with the Precise repo kernels with IOMMU disabled. However, while using an earlier BIOS and kernel 3.0.0, there were occurrences of drives not always being detected even with IOMMU disabled, which I now believe was caused by the BIOS and not related to the kernel used.

[Fredrik Moberg (brelovich)]

I'm having exactly this problem with Marvell 88SE9172 SATA controllers (1b4b:9172) on a Gigabyte X79-UD5 motherboard.

I can see this bug is marked as Incomplete, but I'm not sure exactly why. Could somebody please explain what is missing here?

Maybe I could provide the necessary information.

[madbiologist (me-again)]

@Fredrik - see the last paragraph of comment #8.

[Robert Cicconetti (grythumn)]

This bug also affects my system with an AMD iommu and a Marvell SATA controller. AMD A10-5800K in a Gigabyte GA-F2A85X-D3H motherboard and a Highpoint Rocket 620 (88SE9128). More information available upon request.

[madbiologist (me-again)]

@ Robert - it is always best to mention which version of Ubuntu you are using. Also, in this case, you have a completely different model of Marvell SATA controller so it would be better if you filed a new bug.

[Robert Cicconetti (grythumn)]

@ madbiologist - Sorry, running quantal of the xbuntu/mythbuntu varieties. I went ahead and filed a new bug as suggested, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1089768 although it's the same basic issue, a Marvell sata chipset bug (emitting DMA operations with the wrong PCI device endpoint, which the IOMMU rejects.) Tonight I've confirmed that no one has added a relevant PCI quirk as of 3.7.0rc8 for my devices.

[penalvch (penalvch)]

VB Wright, as per http://www.gigabyte.us/products/product-page.aspx?pid=3891&dl=1#bios an update is available for your BIOS (F11). If you update to this, does it change anything?

If not, could you please test http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8-rc4-raring/ ?

[VB Wright (vbwright)]

Hi Christopher,
There were no changes under the F11 ROM to the IOMMU issue under Fuduntu's
3.6 kernel as of two weeks ago. Also, I'm not currently running Ubuntu, so
I won't be able to test the 3.8 rc4 kernel until I can make a little time
for it, perhaps over the weekend.
On Jan 21, 2013 8:20 PM, "Christopher M. Penalver" <
<email address hidden>> wrote:

> VB Wright, as per http://www.gigabyte.us/products/product-
> page.aspx?pid=3891&dl=1#bios an update is available for your BIOS (F11).
> If you update to this, does it change anything?
>
> If not, could you please test http://kernel.ubuntu.com/~kernel-
> ppa/mainline/v3.8-rc4-raring/ ?
>
> ** Changed in: linux (Ubuntu)
> Status: Confirmed => Incomplete
>
> ** Tags removed: kernel-bug-exists-upstream
> ** Tags added: bios-outdated needs-upstream-testing
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1005226
>
> Title:
> Marvell SATA Controller. Problem booting and detecting HDDs in kernel
> 3.2.0.
>
> Status in “linux” package in Ubuntu:
> Incomplete
>
> Bug description:
> While HDDs conected to my SB950 controller are detected, ones
> connected to the Marvell 88SE9172 Controller are not, also causing a
> significant delay in boot times. This was also present previously when
> when I used kernel 3.0.0 in LinuxMint 12. The affected drives are
> still able to be booted from and recognized within Windows 7.
>
> ## dmesg results for delayed period:
> [ 6.908078] ata9: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [ 6.908948] ata9.00: failed to IDENTIFY (INIT_DEV_PARAMS failed,
> err_mask=0x80)
> [ 12.392060] ata10: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> [ 12.393795] ata10.00: failed to IDENTIFY (device reports invalid
> type, err_mask=0x0)
> [ 17.392075] ata9: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [ 17.392958] ata9.00: failed to IDENTIFY (INIT_DEV_PARAMS failed,
> err_mask=0x80)
> [ 17.392962] ata9: limiting SATA link speed to 1.5 Gbps
> [ 22.876062] ata10: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> [ 22.884055] ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> [ 22.884926] ata9.00: failed to IDENTIFY (INIT_DEV_PARAMS failed,
> err_mask=0x80)
> [ 28.376054] ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
>
> I'm having a similar issue to bug #260543, "JMicron SATA Controller.
> Problem booting with kernel 2.6.24-19. Boots fine with kernel
> 2.6.22-14" [
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/260543 ].
>
> WORKAROUND: Disabled IOMMU in the BIOS.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 12.04
> Package: linux-image-3.2.0-23-generic 3.2.0-23.36
> ProcVersionSignature: Ubuntu 3.2.0-23.36-generic 3.2.14
> Uname: Linux 3.2.0-23-generic x86_64
> NonfreeKernelModules: fglrx
> AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
> ApportVersion: 2.0.1-0ubuntu7
> Architecture: amd64
> AudioDevicesInUse:
> USER PID ACCESS COMMAND
> /dev/snd/controlC1: blairfus 1818 F.... pulseaudio
> /dev/snd/controlC0: blairfu...

[Fredrik Moberg (brelovich)]

Christopher,

I did try the suggested kernel, in Ubuntu Server 12.04, with IOMMU enabled and it didn't seem to solve the problem.

Unfortunately my /var is on one of the disks attached to the affected Marvell controller and once I realized this I had already finished my maintenance window for tonight, so I seem to have no logs from the event.

I will make another attempt to get some useful data during the weekend. I created a /var/log on my root device for the logs. It was missing and I suppose that's why I have nothing for you now.

Please let me know if this sounds all wrong and I should try something else!

[penalvch (penalvch)]

Fredrik Moberg, if you have a bug in Ubuntu, could you please file a new report by executing the following in a terminal:
ubuntu-bug linux

For more on this, please see the Ubuntu Kernel team article:
https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports

the Ubuntu Bug Control team and Ubuntu Bug Squad team article:
https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue

and Ubuntu Community article:
https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Please note, not filing a new report may delay your problem being addressed as quickly as possible.

Thank you for your understanding.

[Fredrik Moberg (brelovich)]

Christopher,

I'm not sure I get it. I'm affected by exactly this bug, that's been reported here, in this bug report.

Are you saying I should report this exact issue as a new bug, somewhere else? That seems like an odd way of doing things.

I'm sorry for the confusion. This is the first time ever that I got involved at all in getting something fixed.

[penalvch (penalvch)]

Fredik Moberg, regarding your comments :

"Christopher, I'm not sure I get it. I'm affected by exactly this bug, that's been reported here, in this bug report."

As documented in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1005226/comments/25 , because you have not filed a new report as previously requested of you, nobody would be able to verify this one way or another. As well, because you are not the original reporter, at this point, your posting comments to this report is not helpful.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

[MvW (2nv2u)]

Still having the same issue up to kernel 3.13 (Trusty tahr development snapshot).
Looks like this will remain an issue for some time to come.

On the bright side, there seems to be some activity on patching a solution upstream:
https://bugzilla.kernel.org/show_bug.cgi?id=42679

[penalvch (penalvch)]

M. van Workum, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[MvW (2nv2u)]

This bug seems to have been fixed some time ago. Could someone back port the patch to 13.10? (3.11)

https://bugzilla.kernel.org/show_bug.cgi?id=42679#c22

[MvW (2nv2u)]

@Christopher

Why do we need to resubmit all bugs we all encounter individually?
The bug is a perfect match to the attached link to the bug on kernel.org which is apparently not fixed upstream yet.
Flooding the system with the same bug seems pointless too me, especially since all related and possible viable comments would be wildly spread across multiple bug reports, what's else is the point of marking this bug affecting me as well?

Why does it need more upstream testing?

[madbiologist (me-again)]

@Christopher

I have to agree with M. van Workum. Regarding your comments in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1005226/comments/25 and https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1005226/comments/30 I would like to make the following comments:

1) The page at https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue is about reporting bugs in Xorg and not the kernel, and as such probably does not apply to kernel bugs. The linux kernel is much more tightly integrated than the xserver and all of it's associated packages.

2) The comments in paragraph 6 at https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette are insulting.

3) The page at https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports is actually relevant and useful, however it does not say anything about filing separate bug reports.

[MvW (2nv2u)]

I agree with madbiologist, although I understand that in some extend the same error (bug) could be a result of different hardware configurations, it all depends on the clarity and how fine grained the report itself is.

Something like my screen turns black sometimes without any back trace or apport report is useless, people shouting they encounter the same on that particular bug without any useful inside makes absolutely no sense. So I agree in this case people should file a new report.

Reporting your findings on a bug report from someone else clearly stating the problem, where some module breaks down in conditions we all can reproduce, seems logical to me.
We all can assume that the more specific the report gets, people with enough experience identifying the same issue are likely to encounter the same thing and help out identify the exact issue. They didn't get to this report with no reason.

In this particular case the correlation is quite clear and seems to be identified as a Marvell SATA driver misbehaving which, in combination with VT-d and the IOMMU kernel module, results in timeouts and not detected storage devices. IMHO resubmitting this bug will be less useful then helping identify it by users how encounter it as well. Especially since it has a bug report on kernel.org stating the same thing. It also ups the heat of this bug making it more important.

We all can agree on some thing though, we are all here to help out making Linux better, so please remain focused doing just that. :)