On Fri, 29 Jan 2010, Alexander Motin wrote: >>> What's interesting, is that Asus board with the same chipset doesn't >>> expose MSI support at all: >>> >>> ahci0_at_pci0:0:17:0: class=0x010601 card=0x43911002 chip=0x43911002 >>> rev=0x00 hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'SB700 SATA Controller [AHCI mode]' >>> class = mass storage >>> subclass = SATA >>> bar [10] = type I/O Port, range 32, base 0xc000, size 8, enabled >>> bar [14] = type I/O Port, range 32, base 0xb000, size 4, enabled >>> bar [18] = type I/O Port, range 32, base 0xa000, size 8, enabled >>> bar [1c] = type I/O Port, range 32, base 0x9000, size 4, enabled >>> bar [20] = type I/O Port, range 32, base 0x8000, size 16, enabled >>> bar [24] = type Memory, range 32, base 0xfbcffc00, size 1024, enabled >>> cap 01[60] = powerspec 2 supports D0 D3 current D0 >>> cap 12[70] = SATA Index-Data Pair >>> >> >> PCI revision register of SMBus device (0:20:0) gives a particular revision of SB7x0. >> SB700 RPR document (section 7.11) says that MSI capability should be disabled if >> the revision is 0x39 or 0x3a, it should be enabled for newer revisions (0x3b, 03c). > > VIA uses ISA bridge to identify chipset, ATI (as you said) - SMBus. > Hell! Why not to do it properly? > >> Those who like to experiment with potentially dangerous things may try playing >> with bit 16 of PCI config register 0x50 of SATA controller device. > > I would prefer it was done by BIOS. Probably ASUS did it, as my board > has 0x3a. Okay, so it's just another case of cheap hardware that's broken by design. Nevertheless thanks for your help. :) Ciao Yamagi -- Homepage: www.yamagi.org Jabber: yamagi_at_yamagi.org GnuPG/GPG: 0xEFBCCBCBReceived on Mon Feb 01 2010 - 06:52:42 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:00 UTC