Bug 15923

Summary: SATA doesn't work on MCP89 chipset
Product: IO/Storage Reporter: Anders Østhus (grapz666)
Component: Serial ATAAssignee: Tejun Heo (tj)
Status: RESOLVED CODE_FIX    
Severity: normal CC: alan, antonmx, betakurv, bryan.ostergaard, damien, dustin.ingram, garrettg84, gschwind, hancockrwd, jason, jmarcet, kernel.5.sunrise77, kernel.roderickmackenzie, ma, martagfranco, mason.larobina, panard, peter.isza, Rebeccaleevans, russell.sim, schlotzky, tigrux, tixetsal, tj
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.32 and 2.6.34-RC7 Subsystem:
Regression: No Bisected commit-id:
Attachments: lspci
Boot dmesg
Dmesg 2.6.34-rc7
Lspci 2.6.34-rc7
dmesg with libata.force=nohrst option enable
dmidecode of an affected macbook pro
dmesg with 2.6.35-rc1 kernel
lspci -nnvvvxxxx
dmesg with "ahci.skip_host_reset=1" kernel option
dmesg of patched and working kernel
config file of working patched kernel
ata_generic.c replacement file of kernel 2.6.35-rc2 (do not use without care)
ata_generic-mbp.patch
ata_generic-dma.patch
dmesg on Macmini4,1 after dma patch
dmesg of mbp 7,1 with dma patch
durty patch that force enable dma
ata_generic-dma.patch
Dmesg when booting from EFI

Description Anders Østhus 2010-05-06 20:06:04 UTC
Created attachment 26266 [details]
lspci

When booting a laptop with MCP89 chipset, no SATA drives are found.
This is tested on a MacBook Pro(7,1)

Also reported in Ubuntu bug tracker: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/576601
Comment 1 Anders Østhus 2010-05-06 20:06:46 UTC
Created attachment 26267 [details]
Boot dmesg
Comment 2 kernel.5.sunrise77 2010-05-08 18:35:38 UTC
i would like to support the fixating. am not a kernel hacker but have a mbp7,1 and i am able to understand what a kernel hacker does :-) would give money to have a fix for this issue. if i can help testing or make logs or dumps etc would be proud to support so. with the fix. plz send instructions. am a java hacker with less c knowledge. plz let me help...
Comment 3 Anders Østhus 2010-05-10 22:27:42 UTC
Also tested on 2.6.34-RC7, and the problem still exists.
Comment 4 Anders Østhus 2010-05-10 22:48:38 UTC
Created attachment 26324 [details]
Dmesg 2.6.34-rc7
Comment 5 Anders Østhus 2010-05-10 22:49:11 UTC
Created attachment 26325 [details]
Lspci 2.6.34-rc7
Comment 6 tixetsal 2010-05-18 00:08:33 UTC
Same problem here.  These folks are experiencing this as well: 
http://ubuntuforums.org/showthread.php?t=1458341&page=10
Comment 7 Roderick MacKenzie 2010-05-29 13:19:27 UTC
Hi,
  Same problem here.  New mac book 7.1 MCP89 chipset. And it can not find the sata disks.  I have tried Umuntu and Fedora 13 (updated to newest kernel), I expect affects all distros.  Would be great if this could be fixed.  I bought the mac book to specificity run linux.  Real shame it does not work.
Cheers,
Rod
Comment 8 Damien Cassou 2010-06-02 07:21:29 UTC
I propose 50€ to get this bug solved:
[url]http://www.cofundos.org/project.php?id=187[/url]

Please add your bid here (even 1€/$ would be cool).
Comment 9 Damien Cassou 2010-06-02 07:22:14 UTC
Correct url is: http://www.cofundos.org/project.php?id=187
Comment 10 kernel.5.sunrise77 2010-06-02 08:00:34 UTC
Thank you Damien Cassou for opening the project at cofundos. I made a bid about 50€ too. I hope there will be anyone who is able to fix this.
Comment 11 Tejun Heo 2010-06-02 13:33:40 UTC
It might be that the current categories are somewhat unintuitive but unless product:component are set to IO/Storage:SerialATA, it can take quite a long time before anyone who works on libata notices the bug report.

Anders, can you please try the following two things?

* Build kernel w/o pata_acpi.

* boot with libata.force=nohrst

Also, just in case this is macbook specific issue (is there any other machine with the same chipset BTW?), please post the output of dmidecode.

Thanks.
Comment 12 Benoit Gschwind 2010-06-02 18:48:16 UTC
Created attachment 26620 [details]
dmesg with libata.force=nohrst option enable

I try to boot the kernel with libata.force=nohrst without success :)

best regards
Comment 13 Benoit Gschwind 2010-06-02 19:03:31 UTC
Created attachment 26621 [details]
dmidecode of an affected macbook pro
Comment 14 Benoit Gschwind 2010-06-02 22:59:15 UTC
Created attachment 26630 [details]
dmesg with 2.6.35-rc1 kernel

kernel 2.6.35-rc1 have the same bug.

If you have suggestion, I have some time to make some test.

best regards
Comment 15 Tejun Heo 2010-06-03 20:15:08 UTC
Can someone please post the output of "lspci -nnvvvxxxx" from linux on the machine?

Thanks.
Comment 16 Dustin Ingram 2010-06-03 20:58:03 UTC
Created attachment 26640 [details]
lspci -nnvvvxxxx
Comment 17 Tejun Heo 2010-06-04 11:30:44 UTC
Does "ahci.skip_host_reset=1" make any difference?

Thanks.
Comment 18 Benoit Gschwind 2010-06-04 12:17:40 UTC
Created attachment 26648 [details]
dmesg with "ahci.skip_host_reset=1" kernel option

no visible difference with "ahci.skip_host_reset=1" kernel option.
Comment 19 Benoit Gschwind 2010-06-11 22:56:14 UTC
Created attachment 26734 [details]
dmesg of patched and working kernel
Comment 20 Benoit Gschwind 2010-06-11 22:58:26 UTC
Created attachment 26735 [details]
config file of working patched kernel
Comment 21 Benoit Gschwind 2010-06-11 23:02:21 UTC
Created attachment 26736 [details]
ata_generic.c replacement file of kernel 2.6.35-rc2 (do not use without care)
Comment 22 Benoit Gschwind 2010-06-11 23:11:51 UTC
Good news, I find a way to use MCP89 IDE on MacBookPro 7,1.

To make it working I use the ata_generic driver patched and disable other drivers (see config file summited). With this patch I can mount and read partition of MacOS X.

I summited the new ata_generic.c file. This patch is durty please do not use it without reviewed it.
Comment 23 Tejun Heo 2010-06-12 17:03:15 UTC
Heh... yeah, earlier today I did similar thing w/ sata_nv although SCR access didn't work (so it basically was behaving as ata_generic as sata_nv doesn't have explicit xfer mode setting callbacks).  So, at this point all that's necessary is making ahci to not take the controller (can be easily matched by subsys id) and add the device ID to either sata_nv or ata_generic.

As sata_nv currently can't do anything more than ata_generic at this point, it would make more sense to add it to ata_generic but I'm reluctant to do it that way because distros often disable ata_generic by default (for a good reason) so it wouldn't work by default on many configurations.  The best thing would be making SCRs work w/ sata_nv so that there's a reason to use sata_nv for it.  I've asked NVIDIA about SCR access in IDE mode on the controller.  I'll push the support upstream once I get response from them.

Thanks.
Comment 24 Benoit Gschwind 2010-06-12 18:08:02 UTC
Curretly I use ata_generic patch with success, I managed to install gentoo linux on MacBookPro 7,1, and I use it now.

Installation was a bit long, because I had to create a bootable CD with patched and correctly configured kernel (boot from external USB drive seems to not work well when you use boot camp).

I hope nvidia will reply soon.
Comment 25 Tejun Heo 2010-06-16 10:25:32 UTC
Created attachment 26806 [details]
ata_generic-mbp.patch

Alright, looks like we'll have to use ata_generic for now at least.  Can you please verify the attached patch works?  It makes ahci reject the controller and ata_generic take it instead.  I'll forward it mainline and -stable once verified.

Thanks.
Comment 26 Peter Isza 2010-06-16 16:54:55 UTC
Hi,

if I have an SSD, will it be much slower with ata_generic than with AHCI? I think for SSD's NCQ makes just overhead, but I'm not sure. Is the bandwidth of the ATA compatibility mode 133Mbyte/s?

Thanks.
Comment 27 Tejun Heo 2010-06-16 17:25:03 UTC
Eh... well, with ata_generic, the controller can't to NCQ so yeah if you have a good SSD, it will suffer performance degradation.
Comment 28 Benoit Gschwind 2010-06-16 21:01:50 UTC
(In reply to comment #25)
> Created an attachment (id=26806) [details]
> ata_generic-mbp.patch
> 
> Alright, looks like we'll have to use ata_generic for now at least.  Can you
> please verify the attached patch works?  It makes ahci reject the controller
> and ata_generic take it instead.  I'll forward it mainline and -stable once
> verified.
> 
> Thanks.

This patch work for me with AHCI and nv_sata enable :)

Do it possible to make reverse engineering to enable SATA ?
Comment 29 Tejun Heo 2010-06-16 22:25:52 UTC
Alright, will forward the patch upstream.  As for reverse engineering, yeah it should be doable but I'll stick to annoying my nvidia contact for the immediate future.  :-)
Comment 30 Roderick MacKenzie 2010-06-16 23:47:31 UTC
Hi All,
  I just tried to apply the patch to the latest Fedora kernel.  It patched, compiled and installed fine.  But when I tried to boot it, it did not work.  It stalled with 'sleeping for ever'  Is there some option in make kernelmenu that must be on for it to work?  Or am I missing some step?
many thanks,
Rod
Comment 31 Benoit Gschwind 2010-06-17 08:02:34 UTC
In my case I apply the on vanilla kernel 2.6.34 and use it on affected MBP. Driver AHCI, nv_sata and ata_generic are built-in.

I hope this help.
Comment 32 Tejun Heo 2010-06-17 08:05:06 UTC
Roderick, was ata_generic included in the initrd?
Comment 33 Tejun Heo 2010-06-17 09:55:45 UTC
Alright, patch forwarded upstream.  Resolving as CODE_FIX.  Thanks.

  http://article.gmane.org/gmane.linux.ide/46514
Comment 34 Roderick MacKenzie 2010-06-17 12:01:02 UTC
Hi Bernoit and Tejun,
  Thanks for your comments.  I included AHCI nv_stat and ata_generic as built in modules and it now boots.
Thanks for your help!
Rod
Comment 35 Peter Isza 2010-06-17 17:42:16 UTC
Very nice, but this IS NOT a real solution. It is like using your brand new nVidia card with the VESA driver...
Comment 36 Robert Hancock 2010-06-18 03:06:57 UTC
Are we missing interrupts with ahci perhaps? From the dmesg it looks like it's using MSI. Has anyone tried booting with "pci=nomsi"?
Comment 37 Tejun Heo 2010-06-18 05:32:33 UTC
Nah.... until that point ahci is still in polling mode. IRQ doesn't play any role yet. IIRC sil24 is the only driver which implements irq driven reset HSM but we poll for completion even there.
Comment 38 Peter Isza 2010-06-19 20:44:48 UTC
I measured the read speeds on a Macbook Pro 7,1 that has a Kingston SSD.

OSX: 198 Mbyte/s
patched Ubuntu: 8.9 Mbyte/s
Comment 39 Robert Hancock 2010-06-20 00:27:04 UTC
That sounds like it's not even using DMA. Can you post dmesg?

The current solution for this chipset is really just a rather poor workaround, there should presumably be some way to get AHCI working on it..
Comment 40 Benoit Gschwind 2010-06-20 09:43:37 UTC
Yes you was right the DMA was disable :

[    2.197787] ata1.00: ATA-8: APPLE SSD TS128B, AGAA0206, max UDMA/100
[    2.197790] ata1.00: 236978176 sectors, multi 16: LBA48
[    2.197808] ata1.00: dma_enabled : 0
[    2.197810] ata1.00: configured for PIO

I patched the kernel to force DMA and that work :

[    2.197788] ata1.00: ATA-8: APPLE SSD TS128B, AGAA0206, max UDMA/100
[    2.197791] ata1.00: 236978176 sectors, multi 16: LBA48
[    2.197808] ata1.00: dma_enabled : ff
[    2.197811] ata1.00: configured for UDMA/100

it seems that Bits that indicate DMA support are false.

best regards

(In reply to comment #39)
> That sounds like it's not even using DMA. Can you post dmesg?
> 
> The current solution for this chipset is really just a rather poor
> workaround,
> there should presumably be some way to get AHCI working on it..
Comment 41 Peter Isza 2010-06-20 23:26:52 UTC
Yes, I will attach the dmesg.

Today we tried to printk the problem out. We didn't have much time, but we have found out that the unpatched kernel can identify the device (although it thinks that my 128GB SSD is only 8MB), it can read from the device once, but after that, the ATA Status Register becomes 0x80 (BUSY), and never changes.

(I have also noted that in the attached dmesg files on this page the detection is correct, and it even identifies the file system before hanging with the BUSY signal.)
Comment 42 Tejun Heo 2010-06-21 10:29:53 UTC
Created attachment 26877 [details]
ata_generic-dma.patch

Can you please apply this patch on top of the mbp patch and see whether DMA gets enabled automatically.  Please attach the kernel boot log.

Thanks.
Comment 43 Benoit Gschwind 2010-06-21 15:45:03 UTC
The last patch fail with : "could no mount root file system"

does it expected ?
Comment 44 Tejun Heo 2010-06-21 15:49:09 UTC
Hmm... not really.  Can you capture the kernel log and post it here?
Comment 45 Koen Calliauw 2010-06-21 16:23:05 UTC
@Tejun Heo: compiling new kernel now, might take a while at PIO speeds
though...

Cheers,
K!
Comment 46 Tejun Heo 2010-06-21 16:24:29 UTC
Oh, just in case I wasn't clear.  The second patch should be applied on top of the first patch.

Thanks.
Comment 47 Benoit Gschwind 2010-06-21 16:56:22 UTC
Yes I did applied 2 patch on kernel 2.6.35-rc3
Comment 48 Koen Calliauw 2010-06-21 18:14:30 UTC
Created attachment 26884 [details]
dmesg on Macmini4,1 after dma patch
Comment 49 Koen Calliauw 2010-06-21 18:16:06 UTC
above is not working, waits for a long time (1 minute or something) before showing the ubuntu splash, then drops me to initramfs.
Comment 50 Koen Calliauw 2010-06-21 18:33:19 UTC
I must have messed something up during the recompile, all the altered .c files are back in their original state. Recompiling now...
Comment 51 Koen Calliauw 2010-06-21 21:57:20 UTC
recompiled twice, once with 2.6.35-4 and once with 2.6.32-22, no joy. so above dmesg should be valid, unless I do something wrong with the compile.
Comment 52 Benoit Gschwind 2010-06-21 22:20:49 UTC
Created attachment 26890 [details]
dmesg of mbp 7,1 with dma patch

I confirm the dma break the previous patch on 2.6.35-rc3, I submited the dmesg log.

My last test was on 2.6.34, and I just set dma_enabled to 0xff before the for loop : ata_for_each_dev(dev, link, ENABLED), and that work.

I didn't find logical error in dma patch, but I just made a quick overview.

Thanks
Comment 53 Benoit Gschwind 2010-06-21 22:30:49 UTC
Created attachment 26891 [details]
durty patch that force enable dma

My durty patch that work, do not use it without caution, don't use it on not affected computer.

Regards
Comment 54 Peter Isza 2010-06-22 00:18:39 UTC
root@opensolaris:~# dd if=/dev/dsk/c8d0 of=/dev/null
^C1413553+0 records in
1413552+0 records out
723738624 bytes (724 MB) copied, 3.78534 s, 191 MB/s
Comment 55 Benoit Gschwind 2010-06-22 07:53:41 UTC
localhost ~ # dd if=/dev/sda3 of=/dev/null 
1290474+0 enregistrements lus
1290474+0 enregistrements écrits
660722688 octets (661 MB) copiés, 3,87454 s, 171 MB/s

ata_generic with DMA enable on MBP 7,1 (SSD 128Go branded apple)
Comment 56 Tejun Heo 2010-06-22 07:56:22 UTC
info@layer7.be: I don't think you have both patches applied.  ahci is still grabbing the controller which shouldn't happen with the first patch applied and the second patch doesn't modify ahci at all.

Benoit: Yeah, well, the second patch should be the same as the dirty patch, only slightly less dirty so that it can go upstream.  Hmmm... It shouldn't affect detection, weird.  Ah, okay.  ata_generic was already using hard coded 1 to check class code matching.  Darn it.  Okay, prepping a new patch.
Comment 57 Tejun Heo 2010-06-22 07:57:33 UTC
Created attachment 26893 [details]
ata_generic-dma.patch

Can you please try this one instead?  Thanks.
Comment 58 Benoit Gschwind 2010-06-22 08:36:48 UTC
The last patch is ok for me :)
Comment 59 Peter Isza 2010-06-22 08:52:46 UTC
Cool. That speed is totally enough for me. Thank you very much. :)
Comment 60 Koen Calliauw 2010-06-22 09:19:17 UTC
@Tejun, is this last patch on top of the original one you made or can I use it by itself?

Thanks.
Comment 61 Damien Cassou 2010-06-22 09:38:48 UTC
@Koen, from Comment 46, "The second patch should be applied on top of
the first patch."
Comment 62 Roderick MacKenzie 2010-06-23 16:46:27 UTC
@Tejun:  I was wondering what happens next, do these patched get submitted up stream now?  And if so when would they start to appear in the distros?  Also, I note on Fedora that ata_genric is only loaded as a module so even if the patch is shipped with the distro, the os will not boot without a recompile to build the ata_genric into the kernel.  Hence, my second question, do you hold out much hope of NVIDIA giving us the specs or solving the firmware issue?
Comment 63 Tejun Heo 2010-06-23 16:52:08 UTC
The patches are already post for mainline inclusion and will be merged soonish.  Once that happens, they'll also be released as part of -stable release, which distros usually include in their kernel updates.  Kernel modules necessary for rootfs are usually loaded from initrd so whether it ends up in a module or in the kernel image doesn't really matter.

As for making ahci support work, it's not too unlikely but I don't know for sure.

Thanks.
Comment 64 Roderick MacKenzie 2010-06-23 16:54:28 UTC
@Tejun:  Thanks, nice to know, and thanks for all your work.
Comment 65 betakurv 2010-06-25 22:54:25 UTC
How do you apply the patches?
I'm just getting hunk failed every time, and i use patch -p0 < "path-to-patch".
Comment 66 Sandino Flores 2010-06-28 19:01:19 UTC
What is the version of the vanilla kernel that will have this fix available?
Thanks for the hard work.
Comment 67 Michael Altmann 2010-06-29 21:40:17 UTC
@betakurv:

1. You should use patch -p1 <... when in kernel root directory.
2. On the debian source tree for 2.6.32 some hunks failed (identifiers changed in ata_generic.c etc.), but it is easy to apply the patches manually.
Comment 68 Peter Isza 2010-07-04 16:56:55 UTC
When booting with grub-efi (without the bios), the original unpatched kernel also works, but interestingly only with CONFIG_EFI=n (and only the VESA framebuffer worked for me.). It recognizes the SATA devices correctly and I have 220MByte/s read speed with my SSD.

The bootup is also a lot quicker, but I can't get the nvidia driver to work. :( Everything else works.
Comment 69 Michael Altmann 2010-07-04 18:20:28 UTC
The nvidia drivers require access to the legacy bios.
Comment 70 Benoit Gschwind 2010-07-05 07:56:51 UTC
Which driver is used with grub-efi, AHCI, SFF or legacy IDE ?

can you provide dmesg log ?

Thanks
Comment 71 Robert Hancock 2010-07-05 23:34:58 UTC
Indeed - if AHCI works with grub-efi, it could be the firmware is just broken for AHCI in non-EFI mode on this machine.
Comment 72 Peter Isza 2010-07-06 17:28:11 UTC
Created attachment 27036 [details]
Dmesg when booting from EFI

When booting from EFI, the AHCI driver seems to work properly. :) The only thing that doesn't work is the nvidia driver, even with a loaded video bios image. :(
Comment 73 Robert Hancock 2010-07-06 23:33:33 UTC
Seems like it's likely some kind of Apple firmware bug then.. Not sure if there's anything that can be done in the kernel to repair the problem to get AHCI working in non-EFI mode.
Comment 74 Javier Marcet 2010-07-11 12:51:34 UTC
Has anyone tried what James McKenzie describes here on http://www.madingley.org/macmini/ ?

I still don't have the new MBP, I'm waiting for it, so I can't test that ATM.

It looks like it could work.

Could anyone give it a try?