Date: Fri, 29 Jan 2010 16:37:36 +0200 From: Alexander Motin <mav@FreeBSD.org> To: Andriy Gapon <avg@icyb.net.ua> Cc: freebsd-current@FreeBSD.org, Yamagi Burmeister <lists@yamagi.org> Subject: Re: Pack of CAM improvements Message-ID: <4B62F2B0.2030704@FreeBSD.org> In-Reply-To: <4B62EDFB.1060103@icyb.net.ua> References: <4B55D9D4.1000008@FreeBSD.org> <alpine.OSX.2.00.1001232228180.2800@idate.home.yamagi.org> <alpine.BSF.2.00.1001281701530.29385@screw.home.yamagi.org> <4B61C688.2050609@FreeBSD.org> <alpine.BSF.2.00.1001281835110.30867@screw.home.yamagi.org> <4B61CCB6.4040005@FreeBSD.org> <alpine.OSX.2.00.1001281922010.4896@idate.home.yamagi.org> <4B62C97F.7080000@FreeBSD.org> <4B62EDFB.1060103@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Andriy Gapon wrote: > on 29/01/2010 13:41 Alexander Motin said the following: >> Yamagi Burmeister wrote: >>> On Thu, 28 Jan 2010, Alexander Motin wrote: >>> >>>>>> Yamagi Burmeister wrote: >>>>>>> ahcich0: is 00000002 cs 00000000 ss 00000000 rs 00000001 tfd 50 serr >>>>>>> 00000000 >>>>>>> ahcich0: Timeout on slot 0 >>>>>> Try to disable MSI interrupts with `hint.ahci.0.msi=0`. >>>>> That fixed the problem. Thank you :) >>>> That's quite strange, as in many other cases IXP700 is working fine. >>>> Different revisions? What is your `pciconf -lvbc` reports? >>> When I helped nox@ debugging a problem with timeouts we noticed, that >>> our controlers are of differend revisions. The pciconf output ist: >>> >>> ahci0@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 0xd000, size 8, enabled >>> bar [14] = type I/O Port, range 32, base 0xc000, size 4, enabled >>> bar [18] = type I/O Port, range 32, base 0xb000, size 8, enabled >>> bar [1c] = type I/O Port, range 32, base 0xa000, size 4, enabled >>> bar [20] = type I/O Port, range 32, base 0x9000, size 16, enabled >>> bar [24] = type Memory, range 32, base 0xfe8ff800, size 1024, >>> enabled >>> cap 01[60] = powerspec 2 supports D0 D3 current D0 >>> cap 05[50] = MSI supports 4 messages, 64 bit >>> cap 12[70] = SATA Index-Data Pair >> What's interesting, is that Asus board with the same chipset doesn't >> expose MSI support at all: >> >> ahci0@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. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B62F2B0.2030704>