On 19 Apr 2010, at 07:30, Alexander Motin <m...@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
every
PCI ATA could work as AHCI. It would be nice to compare `pciconf -
lvbc`
output in both working (Rui) and not working (Michael) cases.
ah...@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
Controller'
class = mass storage
subclass = ATA
^^^
It doesn't report itself as AHCI.
bar [10] = type I/O Port, range 32, base 0x20d8, size 8,
enabled
bar [14] = type I/O Port, range 32, base 0x20fc, size 4,
enabled
bar [18] = type I/O Port, range 32, base 0x20d0, size 8,
enabled
bar [1c] = type I/O Port, range 32, base 0x20f8, size 4,
enabled
bar [20] = type I/O Port, range 32, base 0x2020, size 16,
enabled
bar [24] = type Memory, range 32, base 0x90445000, size 1024,
enabled
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[70] = 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
for
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
probe
stage, but IMHO it's a kind of magic and I wouldn't be doing so.
Ok I'll revert it
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
