SVN rev 206755 breakage
rpaulo at lavabit.com
Mon Apr 19 10:33:23 UTC 2010
On 19 Apr 2010, at 07:30, Alexander Motin <mav at FreeBSD.org> wrote:
> Rui Paulo wrote:
>> On 18 Apr 2010, at 14:05, Alexander Motin wrote:
>>> Most of AHCI controllers could also work as usual PCI ATA, but not
>>> PCI ATA could work as AHCI. It would be nice to compare `pciconf -
>>> output in both working (Rui) and not working (Michael) cases.
>> ahci0 at pci0:0:31:2: class=0x01018f card=0x72708086
>> chip=0x27c48086 rev=0x02 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = '82801GBM/GHM (ICH7-M Family) Serial ATA Storage
>> class = mass storage
>> subclass = ATA
> It doesn't report itself as AHCI.
>> bar  = type I/O Port, range 32, base 0x20d8, size 8,
>> bar  = type I/O Port, range 32, base 0x20fc, size 4,
>> bar  = type I/O Port, range 32, base 0x20d0, size 8,
>> bar [1c] = type I/O Port, range 32, base 0x20f8, size 4,
>> bar  = type I/O Port, range 32, base 0x2020, size 16,
>> bar  = type Memory, range 32, base 0x90445000, size 1024,
> This resource (BAR(5)) is absent on Michael's system. It is needed to
> work in AHCI mode, but not required for legacy PCI ATA. Probably some
> kind of BIOS magic in your case makes it appear in this mode with this
> chip ID.
> On ICH8 and above in non-AHCI mode BAR(5) is also present, but with
> different meaning (access to some SATA registers). So it may be
> difficult to distinguish what exactly we have there.
>> cap 01 = powerspec 2 supports D0 D3 current D0
>> BTW, Mac OS X also uses AHCI on this controller.
> I think Mac OS X is very special beast, which could easily be tuned
> their specific hardware.
> So I think either your patch should be either reverted, or somehow
> improved to check presence of BAR(5) and may be something else on
> stage, but IMHO it's a kind of magic and I wouldn't be doing so.
Ok I'll revert it
More information about the freebsd-current