Date: Wed, 28 Nov 2007 14:51:38 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= <sos@deepcore.dk> To: John Baldwin <jhb@freebsd.org> Cc: Barney Cordoba <barney_cordoba@yahoo.com>, freebsd-current@freebsd.org Subject: Re: Any successful installs on a Broadcom HT1000 chipset? Message-ID: <474D726A.8080807@deepcore.dk> In-Reply-To: <200711280842.09340.jhb@freebsd.org> References: <73807.10710.qm@web63912.mail.re1.yahoo.com> <200711271639.09601.jhb@freebsd.org> <474D1C8C.2060304@deepcore.dk> <200711280842.09340.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > On Wednesday 28 November 2007 02:45:16 am S=F8ren Schmidt wrote: > =20 >> John Baldwin wrote: >> =20 >>> FYI, I've seen weird in-memory corruption with machines with the HT10= 00_S1=20 >>> atapci device. In all the cases I've seen so far, a single page is c= orrupted=20 >>> with garbage and the page happens to be used by UMA to hold credentia= ls=20 >>> including proc0's credentials. I've seen this corruption (trashed cr= eds for=20 >>> proc0 and other creds in that page) on many of the same boxes (Dell 1= 435's=20 >>> IIRC) running on 6.2. I've tried switching the HT1000_S1 to use SWKS= MIO=20 >>> rather SWKS100 as I mentioned to you in an earlier e-mail (the Linux = driver=20 >>> uses equivalent of SWKSMIO FWIW) but don't have any conclusive tests = on that. >>> >>> =20 >>> =20 >> OK, seems the chipset has some real problems, I have digged through al= l=20 >> the (very little) docs and info I got from serverworks back when, and = >> the only thing I can find is that the chips doesn't support MSI in any= =20 >> shape or fashion or it will do really strange things. >> Now on my system it seems to be disabled but I'm not sure yet how its = >> determined to be that way. Would be worth for you guys to check what t= he=20 >> sysctl's "hw.pci.enable_msi" and "hw.pci.enable_msix" are set to. >> I havn't looked into this yet, but I'm pretty sure we added MSI suppor= t=20 >> in the 6.2 -> 7.0 timeframe, so that might have uncovered this chipset= =20 >> bug, and possibly the Promise data corruption one as well. >> =20 > > The ata driver doesn't use MSI (no calls to pci_msi_count or pci_msi_al= loc, > etc.), so this isn't an issue. Also, the boxes I've seen the corruptio= n on > already have MSI disabled (it's still disabled by default in 6.x). > =20 OK, its must be *totally* disabled not just for ATA but for everything=20 on those chipsets or they'll barf all over the place. If we do that already we need to look into other places. However, if we are dealing with in-memory corruption this is going to=20 get "interesting".... Does that also happen if nothing uses DMA ? -S=F8ren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?474D726A.8080807>