Bug 15923

Created attachment 26267 [details]
Boot dmesg

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...

Also tested on 2.6.34-RC7, and the problem still exists.

Created attachment 26324 [details]
Dmesg 2.6.34-rc7

Created attachment 26325 [details]
Lspci 2.6.34-rc7

Same problem here.  These folks are experiencing this as well: 
http://ubuntuforums.org/showthread.php?t=1458341&page=10

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

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).

Correct url is: http://www.cofundos.org/project.php?id=187

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.

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.

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

Created attachment 26621 [details]
dmidecode of an affected macbook pro

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

Can someone please post the output of "lspci -nnvvvxxxx" from linux on the machine?

Thanks.

Created attachment 26640 [details]
lspci -nnvvvxxxx

Does "ahci.skip_host_reset=1" make any difference?

Thanks.

Created attachment 26648 [details]
dmesg with "ahci.skip_host_reset=1" kernel option

no visible difference with "ahci.skip_host_reset=1" kernel option.

Created attachment 26734 [details]
dmesg of patched and working kernel

Created attachment 26735 [details]
config file of working patched kernel

Created attachment 26736 [details]
ata_generic.c replacement file of kernel 2.6.35-rc2 (do not use without care)

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.

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.

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.

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.

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.

Eh... well, with ata_generic, the controller can't to NCQ so yeah if you have a good SSD, it will suffer performance degradation.

(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 ?

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.  :-)

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

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.

Roderick, was ata_generic included in the initrd?

Alright, patch forwarded upstream.  Resolving as CODE_FIX.  Thanks.

  http://article.gmane.org/gmane.linux.ide/46514

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

Very nice, but this IS NOT a real solution. It is like using your brand new nVidia card with the VESA driver...

Are we missing interrupts with ahci perhaps? From the dmesg it looks like it's using MSI. Has anyone tried booting with "pci=nomsi"?

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.

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

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..

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..

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.)

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.

The last patch fail with : "could no mount root file system"

does it expected ?

Hmm... not really.  Can you capture the kernel log and post it here?

@Tejun Heo: compiling new kernel now, might take a while at PIO speeds
though...

Cheers,
K!

Oh, just in case I wasn't clear.  The second patch should be applied on top of the first patch.

Thanks.

Yes I did applied 2 patch on kernel 2.6.35-rc3

Created attachment 26884 [details]
dmesg on Macmini4,1 after dma patch

above is not working, waits for a long time (1 minute or something) before showing the ubuntu splash, then drops me to initramfs.

I must have messed something up during the recompile, all the altered .c files are back in their original state. Recompiling now...

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.

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

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

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

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)

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.

Created attachment 26893 [details]
ata_generic-dma.patch

Can you please try this one instead?  Thanks.

The last patch is ok for me :)

Cool. That speed is totally enough for me. Thank you very much. :)

@Tejun, is this last patch on top of the original one you made or can I use it by itself?

Thanks.

@Koen, from Comment 46, "The second patch should be applied on top of
the first patch."

@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?

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.

@Tejun:  Thanks, nice to know, and thanks for all your work.

How do you apply the patches?
I'm just getting hunk failed every time, and i use patch -p0 < "path-to-patch".

What is the version of the vanilla kernel that will have this fix available?
Thanks for the hard work.

@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.

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.

The nvidia drivers require access to the legacy bios.

Which driver is used with grub-efi, AHCI, SFF or legacy IDE ?

can you provide dmesg log ?

Thanks

Indeed - if AHCI works with grub-efi, it could be the firmware is just broken for AHCI in non-EFI mode on this machine.

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. :(

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.

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?