This issue persists in 2.6.18-164.el5 Linux localhost.localdomain 2.6.18-164.el5 #1 SMP Thu Sep 3 03:33:56 EDT 2009 i686 i686 i386 GNU/Linux The Marvell controller in question is: Marvell 88SE61xx This is a 4SATA controller with optional hardware RAID, if RAID is not configured each SATA drive shows in the BIOS as an SCSI device, if RAID is configured one SCSI device show for each configured array. Could the fixes from the original bug be backported? I have attached the following as a single tgz, lspci.output (lspci -nn & lspci -vv) dmesg.output dmidecode.output Regards D.Busby +++ This bug was initially created as a clone of Bug #455833 +++ Description of problem: The PATA Marvell 88SE6121 controller found in many ASUS motherboards is not being detected correctly on boot. It works properly during the F9 DVD installer as it installs Fedora just fine, but after boot up into the real install the DVD drive is no longer detected. pata_marvell is also not loaded. modprobing pata_marvell results in no detection of anything. Version-Release number of selected component (if applicable): All F9 kernels. How reproducible: Always Actual results: Marvell chip is not detected. Expected results: Chip detection and DVD drive functionality Additional info: There is a fix for this... if I make a special initrd that preloads the pata_marvell module everything works great. I used this as a band aid as I thought a kernel update would fix this, but it's been a few updates and this problem still exists. --- Additional comment from cebbert on 2008-07-18 12:11:49 EDT --- Can you post the output of the command 'lspci -nn'? --- Additional comment from mike on 2008-07-18 12:20:00 EDT --- Created an attachment (id=312151) lspci output This is the output from lspci -nn. I also included the lspci -vv output in the same file, just in case it comes up. --- Additional comment from mike on 2008-07-18 12:20:30 EDT --- Fulfilled NEEDINFO. --- Additional comment from sgallagh on 2008-08-04 16:08:05 EDT --- I'd like to recommend that the priority of this issue be raised. It appears that this bug also affects some MSI boards using the same Marvell 88SE6121 chipset. --- Additional comment from pjones on 2008-08-04 16:20:29 EDT --- The initrd shouldn't be loading this driver; that should happen later. --- Additional comment from beto.ar on 2008-08-04 16:32:58 EDT --- Created an attachment (id=313399) This is my dmesg output --- Additional comment from beto.ar on 2008-08-04 16:34:22 EDT --- Created an attachment (id=313400) This is my dmidecode output This is my dmidecode output --- Additional comment from beto.ar on 2008-08-04 16:35:32 EDT --- Created an attachment (id=313401) This is my lspci output This is my lspci output my mb is an MSI with Marvell drivers --- Additional comment from beto.ar on 2008-08-04 16:54:25 EDT --- My temporary fix: Add on /etc/modprobe.d/blacklist blacklist ahci save and reboot --- Additional comment from wrowe on 2008-08-05 21:17:00 EDT --- Confirming Alberto's observation on blacklisting ahci, with the kernel build 2.6.25.11-97.fc9.x86_64 Had tried all of the common workarounds and specific hacks proposed throughout the internet with respect to this problem. Only blacklisting ahci is successful. Note that the pata_marvell might really need exclusive preloading if only to ensure the h/w is initialized correctly in the proper order. Even after blacklisting, ahci is started. However I suspect pata_marvell is exclusively loaded, first, giving it the first shot at owning this device mapping. The resulting driver group is; # lsmod | grep ata pata_marvell 13568 1 libata 149664 2 ahci,pata_marvell scsi_mod 150360 5 usb_storage,sr_mod,sg,sd_mod,libata The affected device map consists of two controllers on the ASUS P5Q Deluxe motherboard hosting 2 SATA drives, usb memdrives and 1 PATA DVD r/w. It's the DVD unit which is not detected with default drivers. 00:1f.2 SATA controller: Intel Corporation ICH10 6 port SATA AHCI Controller (pr og-if 01 [AHCI 1.0]) Subsystem: ASUSTeK Computer Inc. Unknown device 82d4 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort - <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin B routed to IRQ 19 Region 0: I/O ports at 9c00 [size=8] Region 1: I/O ports at 9880 [size=4] Region 2: I/O ports at 9800 [size=8] Region 3: I/O ports at 9480 [size=4] Region 4: I/O ports at 9400 [size=32] Region 5: Memory at fe7fe800 (32-bit, non-prefetchable) [size=2K] Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/4 Enable- Address: 00000000 Data: 0000 Capabilities: [70] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a8] SATA HBA <?> Capabilities: [b0] Vendor Specific Information <?> Kernel driver in use: ahci Kernel modules: ahci 03:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6121 SATA II Controller (rev b1) (prog-if 8f [Master SecP SecO PriP PriO]) Subsystem: ASUSTeK Computer Inc. Unknown device 8212 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 16 Region 0: I/O ports at dc00 [size=8] Region 1: I/O ports at d880 [size=4] Region 2: I/O ports at d800 [size=8] Region 3: I/O ports at d480 [size=4] Region 4: I/O ports at d400 [size=16] Region 5: Memory at feaffc00 (32-bit, non-prefetchable) [size=1K] Capabilities: [48] Power Management version 2 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0+,D1+,D2-,D3hot +,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=1 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Address: 00000000 Data: 0000 Capabilities: [e0] Express (v1) Legacy Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited , L1 unlimited ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupporte d- RlxdOrd- ExtTag- PhantFunc- AuxPwr+ NoSnoop- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPe nd- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 < 256ns, L1 unlimited ClockPM- Suprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive - BWMgmt- ABWMgmt- Kernel driver in use: pata_marvell Kernel modules: ata_generic, pata_acpi, pata_marvell, ahci --- Additional comment from cebbert on 2008-08-12 13:04:07 EDT --- Looking at the code in ahci.c, it is supposed to only claim the first two ports on the 6121 adapter. (commit c40e7cb89f9d36924131ef708ff1f16a76611add) According to the dmesg it is doing that: ahci 0000:03:00.0: MV_AHCI HACK: port_map 7 -> 3 So there must be some unusual reason why pata_marvell can't find any devices when it loads after ahci. --- Additional comment from alan on 2008-08-12 13:20:59 EDT --- . I've been complaining about this mess for ages now. I pointed it out when Jeff broke the marvell support but he didn't revert it and didn't fix it. You can't make it work with current kernels. There is a single PCI device which is owned by the AHCI driver and the PATA port in AHCI mode needs to handled by this driver with some extra mode setting bits. Jeff I believe has the docs to fix it, which should then be fairly easy to do. If you go back to about 2.6.23 it should all work ok. Chuck: You need to grab Jeff by a suitable bit of his anatomy and remind him about this. I've tried. If you can get the docs out of him I can probably fix it too. Alternatively I have a patch he will hate that kicks the chip out of AHCI mode --- Additional comment from alan on 2008-08-12 16:44:40 EDT --- Reassigned away. I can do nothing about this bug. Jeff has the docs not me. --- Additional comment from ablishen.au on 2008-08-27 11:52:54 EDT --- Has there been any progress on this ? Can this be made a higher priority as it prevents installation on a lot of systems ? I hope this is at least fixed in Fedora 10 --- Additional comment from lmedinas on 2008-08-28 18:10:37 EDT --- Well i suffer the same problem but i could install f9 and it's running ok except my dvd/cdrom drives doesn't work. I had to regenerate a new initrd with pata_marvell preload to fix my problem. --- Additional comment from cebbert on 2008-09-11 02:48:42 EDT --- I've applied the first, simpler patch that unconditionally disables ahci for those adapters. pata_marvell will always be used even with no PATA devices attached. --- Additional comment from updates on 2008-09-14 02:14:20 EDT --- kernel-2.6.26.5-39.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/kernel-2.6.26.5-39.fc9 --- Additional comment from updates on 2008-09-16 19:21:23 EDT --- kernel-2.6.26.5-39.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-8089 --- Additional comment from wrowe on 2008-09-18 13:29:21 EDT --- Confirming #10 is resolved in kernel-2.6.26.5-39.fc9, SATA remain scsi0-5, PATA are correctly picked up, beginning at scsi6. Thanks folks. --- Additional comment from mike on 2008-09-18 19:00:29 EDT --- Confirming fix as well. Thanks for your efforts, Chuck. --- Additional comment from updates on 2008-09-20 02:30:00 EDT --- kernel-2.6.26.5-44.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/kernel-2.6.26.5-44.fc9 --- Additional comment from updates on 2008-09-24 20:16:57 EDT --- kernel-2.6.26.5-45.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-8283 --- Additional comment from ablishen.au on 2008-09-29 08:57:30 EDT --- I have an ASUS P5Q Deluxe Motherboard with ICH10R 6 SATA ports and the Marvell with 2 SATA, eSATA and IDE This kernel update disable the Marvell SATA ports. The Marvell controller works under Fedora 8 --- Additional comment from cebbert on 2008-09-29 19:02:39 EDT --- (In reply to comment #23) > I have an ASUS P5Q Deluxe Motherboard with ICH10R 6 SATA ports and the Marvell > with 2 SATA, eSATA and IDE > > This kernel update disable the Marvell SATA ports. > > The Marvell controller works under Fedora 8 Which update disabled the Marvell SATA ports? --- Additional comment from wrowe on 2008-09-29 19:16:50 EDT --- For background, the 2 Marvell SATA ports had not worked for some time (long before this fix); I discovered this working around the PATA bug by unsuccesfully installing a DVDrw drive into one of those SATA ports. Note that these two are entangled in Asus's EZ-Drive BIOS feature and there is quite possibly some additional configuration required in order to use them. This PATA fix has no apparent effect on that SATA flaw either way. --- Additional comment from ablishen.au on 2008-09-30 15:03:15 EDT --- The update I applied was kernel-2.6.26.5-45.fc9.x86_64 Also I left out Fedora 8 works using the default kernel 2.6.23.1 It should be possible to see what was changed / broken between 2.6.23.1 and 2.6.25 Also 2.6.25 update for Fedora 8 will has the same issues as with Fedora 9 and I expect Fedora 10 as well. Although there is no option in the BIOS to set ACHI/IDE modes for the Marvell 88SE6121 controller just turn on/off the Silicon Image Sil5723 (Drive Xpert technology) that is connected to the Marvell 88SE6121 controller. The Marvell 88SE6121 controller seems to be set to ACHI. Also the manual says that Optical SATA drives will not work with the Marvell controller only hard drives. --- Additional comment from updates on 2008-10-01 02:36:48 EDT --- kernel-2.6.26.5-45.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report. --- Additional comment from john.robinson.uk on 2009-08-13 09:26:16 EDT --- This bug seems to have reappeared in Enterprise Linux. I have an Asus P5Q Pro motherboard with Intel ICH10R SATA and Marvell 88SE6121 SATA and IDE ports: 00:1f.2 SATA controller: Intel Corporation 82801JI (ICH10 Family) SATA AHCI Controller 03:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6121 SATA II Controller (rev b2) In kernel 2.6.18-92.1.22, I can use my IDE DVD-ROM drive, and see the following in the syslog at boot time: Aug 13 09:12:26 beast kernel: ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 16 (lev el, low) -> IRQ 16 Aug 13 09:12:26 beast kernel: scsi6 : pata_marvell Aug 13 09:12:26 beast kernel: scsi7 : pata_marvell Aug 13 09:12:26 beast kernel: ata7: PATA max UDMA/100 cmd 0xdc00 ctl 0xd880 bmdm a 0xd400 irq 16 Aug 13 09:12:26 beast kernel: ata8: PATA max UDMA/133 cmd 0xd800 ctl 0xd480 bmdm a 0xd408 irq 16 Aug 13 09:12:26 beast kernel: BAR5:00:02 01:7F 02:22 03:CA 04:00 05:00 06:00 07: 00 08:00 09:00 0A:00 0B:00 0C:07 0D:00 0E:00 0F:00 Aug 13 09:12:26 beast kernel: ata7.00: ATAPI: HL-DT-STDVD-RAM GH22NP20, 1.02, ma x UDMA/66 Aug 13 09:12:26 beast kernel: ata7.00: configured for UDMA/66 Aug 13 09:12:26 beast kernel: BAR5:00:02 01:7F 02:22 03:CA 04:00 05:00 06:00 07: 00 08:00 09:00 0A:00 0B:00 0C:07 0D:00 0E:00 0F:00 Aug 13 09:12:26 beast kernel: Vendor: HL-DT-ST Model: DVD-RAM GH22NP20 Rev: 1.02 Aug 13 09:12:26 beast kernel: Type: CD-ROM ANSI SCSI revision: 05 But in kernel 2.6.18-128.4.1, I can't, and I see the following instead: Aug 13 09:21:40 beast kernel: ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 16 (lev el, low) -> IRQ 16 Aug 13 09:21:40 beast kernel: ahci 0000:03:00.0: controller can't do NCQ, turnin g off CAP_NCQ Aug 13 09:21:40 beast kernel: ahci 0000:03:00.0: MV_AHCI HACK: port_map 7 -> 3 Aug 13 09:21:40 beast kernel: ahci 0000:03:00.0: AHCI 0001.0000 32 slots 3 ports 3 Gbps 0x3 impl IDE mode Aug 13 09:21:40 beast kernel: ahci 0000:03:00.0: flags: 64bit stag led pmp slum part Aug 13 09:21:40 beast kernel: scsi6 : ahci Aug 13 09:21:40 beast kernel: scsi7 : ahci Aug 13 09:21:40 beast kernel: scsi8 : ahci Aug 13 09:21:40 beast kernel: ata7: SATA max UDMA/133 abar m1024@0xfafffc00 port 0xfafffd00 irq 16 Aug 13 09:21:40 beast kernel: ata8: SATA max UDMA/133 abar m1024@0xfafffc00 port 0xfafffd80 irq 16 Aug 13 09:21:40 beast kernel: ata9: DUMMY Aug 13 09:21:40 beast kernel: ata7: SATA link down (SStatus 0 SControl 300) Aug 13 09:21:40 beast kernel: ata8: SATA link down (SStatus 0 SControl 300) So the AHCI driver is now picking up the Marvell controller, and if it's a choice between its 2 SATA ports which I'm not using or its 1 IDE port which I am, I'd rather have the IDE port. Is there a workaround to stop the AHCI driver claiming the Marvell controller? --- Additional comment from mike on 2009-08-13 09:35:02 EDT --- Either (In reply to comment #28) > > Is there a workaround to stop the AHCI driver claiming the Marvell controller? Either read my comment in "Additional info" or an alternative is posted in comment #9. Try one or both. After finding out this hardware doesn't support hotswap the hard way (eSATA) just yesterday (affects Windows, too), I'd be inclined to say stay away from Marvell products. ASUS went cheap on us and put on some low-grade ICs. --- Additional comment from john.robinson.uk on 2009-08-13 11:10:16 EDT --- D'oh! Thanks for that. I wanted a workaround which would stick through kernel updates, and you encouraged me to poke around mkinitrd a little more. I have now created an /etc/sysconfig/mkinitrd/preload-pata_marvell file which contains PREMODS="pata_marvell $PREMODS" and re-run mkinitrd; hopefully this will be included automatically when there's another kernel update. --- Additional comment from ablishen.au on 2009-08-22 12:54:27 EDT --- This has been fixed in kernel 2.6.27
Created attachment 366274 [details] archive file with output information Attach on create failed, adding manually.
Would you please test kernel-2.6.18-172.el5.bz531264? It includes a backport of the upstream fix for BZ 455833. commit 5b66c829bf5c65663b2f68ee6b42f6e834cd39cd ahci, pata_marvell: play nicely together http://people.redhat.com/dmilburn/.bz531264/
Created attachment 369196 [details] Outputs post deploy of supplied kernel Unfortunately this does not appear to have resolved the issue, attached are the relevant outputs. Cheers D.Busby
I think your problem is slightly different than BZ 455833, the problem in 455833 was ahci driver claiming the marvell controller but not able to drive the PATA port. The upstream fix mentioned in Comment #2 includes a module parameter which allows the ahci driver to drive SATA ports controlled by the Marvell controller and pata_marvell driver to drive PATA ports controller by the Marvell controller. You should be able to edit /etc/modprobe.conf, add an entry for ahci before pata_marvell, and set the module parameter to allow ahci to drive the SATA drives. alias scsi_hostadapter ahci options ahci marvell_enable=1 Rebuild your initrd for the debug kernel (Comment #2) mv /boot/initrd-$(uname -r).img /boot/initrd-$(uname -r).img.backup mkinitrd -v -f /boot/initrd-$(uname -r).img $(uname -r) Reboot and let ahci driver drive the SATA ports, please see if your drives are recognized.
This Bugzilla has been reviewed by Red Hat and is not planned on being addressed in Red Hat Enterprise Linux 5, and therefore is being closed. If this bug is critical to production systems, please contact your Red Hat support representative and provide a sufficient business justification in order to re-open it.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days