Date: Wed, 13 Sep 2006 09:19:07 -0600 From: Scott Long <scottl@samsco.org> To: John Baldwin <jhb@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Norikatsu Shigemura <nork@FreeBSD.org>, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/amd64/amd64 mp_machdep.c src/sys/i386/i386 mp_machdep.c Message-ID: <4508216B.3060400@samsco.org> In-Reply-To: <200609131032.43068.jhb@freebsd.org> References: <200609112010.k8BKAgWI092204@repoman.freebsd.org> <20060913223331.4024c2bc.nork@FreeBSD.org> <200609131032.43068.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > On Wednesday 13 September 2006 09:33, Norikatsu Shigemura wrote: > >>On Mon, 11 Sep 2006 20:10:42 +0000 (UTC) >>John Baldwin <jhb@freebsd.org> wrote: >> >>>jhb 2006-09-11 20:10:42 UTC >>> FreeBSD src repository >>> Modified files: >>> sys/amd64/amd64 mp_machdep.c >>> sys/i386/i386 mp_machdep.c >>> Log: >>> Actually hook up the IPI_INVLCACHE IDT vectors backing >>> pmap_invalidate_cache() in the SMP case so pmap_mapdev() in multiuser >>> doesn't panic with a trap 30. I broke this many months ago when I >>> added pmap_invalidate_cache() as early parts of the PAT work. >>> Patience from: jmg >>> Pointy hat: jhb >> >> Cool!!! >> My radeon+smp problem was fixed!! Thank you. > > > Yeah, this should fix all the 'trap 30' panics on SMP x86 when you kldload a > driver. > This would explain why I was about to toss my test machine out the window. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4508216B.3060400>