Date: Fri, 12 Mar 2010 17:57:44 +0100 From: Pierre Beyssac <pb@freebsd.org> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: mav@freebsd.org, freebsd-stable@freebsd.org Subject: (fixed) Re: 8-STABLE interrupt storm on atapci(?), Dell Inspiron 580 Message-ID: <20100312165744.GA86971@fasterix.frmug.org> In-Reply-To: <20100312131832.GA54731@icarus.home.lan> References: <20100312121409.GA79294@fasterix.frmug.org> <20100312131832.GA54731@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
--G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Mar 12, 2010 at 05:18:32AM -0800, Jeremy Chadwick wrote: > I'm a little confused by the kernel output. It appears as if you're > using the new SATA-to-CAM layer (ahci.ko) for your SATA disks, rather > than the ataahci.ko layer... but I don't see any indication of AHCI > being available/used on your southbridge chipset. ahci.ko is not compiled in or loaded as a module, however in the course of debugging the problem I added option ATA_CAM, which seems to result in /dev/ada0*. Removing the option to get back to /dev/ad4* doesn't fix the problem. BTW ATA_CAM seems to work fine with generic ATA but not with ataintel. > Possibly this is the source of the problem (specifically, it looks like > FreeBSD doesn't have proper device ID knowledge of what this controller > is. I believe that's because this system is *very* new, a Core i3/i5/i7 > system)? I didn't notice that, you're right! The system is brand new, got it delivered on Tuesday. Another odd thing is that the controllers have differents IDs, 0x3b208086 vs 0x3b268086. I added the IDs to ata-intel.c and it fixes the problem. Preparing a patch. Thanks for the hint! -- Pierre Beyssac pb@fasterix.frmug.org --G4iJoqBmSsgzjUCe--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100312165744.GA86971>