Bug 12075 (Marvell)
Summary: | Kernel 2.6 fails to install / run on Marvell 6145 SATA Controller | ||
---|---|---|---|
Product: | Platform Specific/Hardware | Reporter: | andrei (grip2die) |
Component: | x86-64 | Assignee: | platform_x86_64 (platform_x86_64) |
Status: | CLOSED CODE_FIX | ||
Severity: | blocking | CC: | alan, egross, jgarzik, jrnieder, tj |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.27.5 | Subsystem: | |
Regression: | No | Bisected commit-id: |
Description
andrei
2008-11-21 04:33:22 UTC
I have 2 hdds and 1 dvd-drive attached to the Marvell 6145 controller. The Windows (XP Home Edition SP2) runns perfectly, but the SUSE 11.0, 11.1b4, 11.1b5 fails to install: doesn't recognize neither the hdds, nor the dvd-drive. I have taken some screenshots. Hope it helps... https://bugzilla.novell.com/attachment.cgi?id=250910 https://bugzilla.novell.com/attachment.cgi?id=250911 https://bugzilla.novell.com/attachment.cgi?id=250912 On the Asus website (http://dlsvr01.asus.com/pub/ASUS/mb/socket775/P5K_SE/Marvell.zip), you can find Marvell SATA code source and documentation that explain how to build and install the linux driver for Marvell SATA controller. This code source is for 'Marvell Storage Controller 6121/6122/6141/6145'. The code source version is v1.0.0.9 for Marvell SATA Controller and was developed by a Marvell's developer. Reassigned to ata.. IRQ routing problem, reassigned to x86 It is now a year and a half since I first reported this bug: the leak of a decent driver in the standard linux kernel for "Marvell 6145 SATA2 Controller". This controller is on a mainstream Intel motherboard (975X Bad Axe 2), so one would expect linux to be able to utilize it. Alan, why did you think it was a IRQ routing problem? andrei, have you tried newer distros? Also, what is the original novell bug number? The traces seem to show the IRQ not being delivered. Also the chip is known to work on other setups, although Jeff still hasn't finished his extended PATA patches tio make it really fly. "The chip just isn't popular enough and is pretty tricky to support properly." :) https://bugzilla.novell.com/show_bug.cgi?id=398337 "drivers are kernel business" https://bugzilla.novell.com/show_bug.cgi?id=398337 (In reply to comment #6) > Alan, why did you think it was a IRQ routing problem? andrei, have you tried > newer distros? Also, what is the original novell bug number? Marvell 6145 controller situation @ Nov 2008: MS WinXP Home Edition works *** perfectly *** with proprietary drivers openSUSE 11.0 - fails to install openSUSE 11.1 beta 4 - fails to install openSUSE 11.1 beta 5 - fails to install Marvell 6145 controller situation @ Apr 2010: Not known, because now I only use the Intel SATA controller. Okay, now I remember. The NDA process took something like six months and I lost track of things. Jeff, this is the weird ahci-like pata chip, right? Are you gonna work on it? Thanks. I run debian kernel 2.6.32-5-amd64 on a Asus M2V motherboard. It has a Marvell sata controller for external hd (88SE6121 SATA II). Boot hangs a long time if the external hd is attached. I found a workaround putting "options ahci marvell_enable=1" in an archive in /etc/modprobe.d. I found a discussion on that issue at debian bug report (http://bugs.debian.org/515201), where details of my and another case are dealt with. There I was adviced to put the question here too. As I do not have enough technical knowledge, I ask to look the suggestions made there, especially by Jonathan Nieder. Thanks. egross@bol.com.br To summarize: various people using SATA drives attached to Marvell controllers with a 2.6.32.y kernel have been having trouble (failed IDENTIFY, SRST taking a long time). Passing ahci.marvell_enable=1 avoids trouble. If I understand 5b66c829bf5c (ahci, pata_marvell: play nicely together, 2008-09-03) correctly, that is not supposed to be necessary: | The actual fix for the moment is very simple. If the user has included | the pata_marvell driver let it drive the ports. If they've only selected | for SATA support give them the AHCI driver which will run the port a fraction | faster. Allow the user to control this decision via ahci.marvell_enable as | a module parameter so that distributions can ship 'it works' defaults and | smarter users (or config tools) can then flip it over it desired. What upstream commit might have fixed this? Reopening, but information on fixed versions would still of course be welcome. (In reply to comment #14) > information on fixed versions would still of course be welcome. (and status on 3.x.y kernels in general) See git log drivers/ata/ahci.c (In reply to comment #16) > See > > git log drivers/ata/ahci.c Sorry, it's still not obvious which commit you're referring to. The only commit after 2.6.32 I can see that touches this code is 394d6e535f15 ("ahci: Factor out PCI specifics from ahci_save_initial_config()", 2010-03-03) and I do not see how it could have changed anything. 5b66c829bf5c ("ahci, pata_marvell: play nicely together", 2008-09-03) is the commit that introduced the marvell_enable parameter. That can't possibly be the fix, given that these reports mention that setting marvell_enable works around the problem with a cost of (apparently) stopping the PATA driver from driving the PATA ports. The marvell_enable option forces the device to be handled by the AHCI driver, which doesn't support PATA mode. Otherwise if the Marvell driver is built in the pata_marvell driver handles all the ports, but within the limits of the hardware IDE support. The other relevant change is cb6643e1c38b6bd5c1594f0a45d8cf6943a6f934 Does "within the limits of the hardware IDE support" mean failed IDENTIFY, SRST taking a long time, and so on? If so, I think it would probably be best to (in distro builds) make ahci.marvell_enable default to 1, even when the pata_marvell driver has also been enabled as a module. the idea case would be someone wrote the needed support. However Marvell only ever gave the docs to one person and they never had time to do it as its very complicated to handle. Basically they have an AHCI-like PATA mode that is unique to their devices. (In reply to comment #20) > the idea case would be someone wrote the needed support. However Marvell only > ever gave the docs to one person and they never had time to do it as its very > complicated to handle. Basically they have an AHCI-like PATA mode that is > unique to their devices. Makes sense. And looks like cb6643e1c38b ([libata] pata_marvell: CONFIG_AHCI is really CONFIG_SATA_AHCI) will do just what one would want in the meantime. Thanks for digging it up. |