Date: Mon, 1 May 2006 15:29:04 -0400 From: John Baldwin <jhb@freebsd.org> To: Maxim Sobolev <sobomax@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, Nate Lawson <nate@root.org> Subject: Re: cvs commit: src/sys/dev/sk if_sk.c if_skreg.h Message-ID: <200605011529.07817.jhb@freebsd.org> In-Reply-To: <44565DC9.5020102@FreeBSD.org> References: <200604280317.k3S3Hb3L017882@repoman.freebsd.org> <200605011124.09330.jhb@freebsd.org> <44565DC9.5020102@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 01 May 2006 15:13, Maxim Sobolev wrote: > John Baldwin wrote: > > >> BTW, can you check the following URL, it's the changes intel has made > >> to ia32 manual after releasing Core Duo. Maybe you can spot something > >> there. There are some lapic-related changes. > >> > >> http://download.intel.com/design/Pentium4/specupdt/25204616.pdf > > > > None of the APIC-related changes affect us. We always access APIC > > registers using 32-bit loads and stores for example. > > I see, do you have any other ideas why it doesn't work on FreeBSD, while > works OOB on Linux 2.6 (reportedly) and definitely on Windows XP SP2? > Anything specific in our way of lapic/SMP handling? Nope. > BTW, I have noticed that we don't mark lapic page as noncacheable, which > seemingly required by the spec. I have made small change (3 lines), but > it doesn't help either. You can also try the PAT patch which would have the side effect of forcing the lapic to be mapped UC as well. > -Maxim > P.S. I will bring the laptop to BSDCan so that I can let you or anybody > else play with it if it helps to fix the problem. Ok, I'll be there. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200605011529.07817.jhb>