Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On 3/1/19 5:03 AM, Rodney W. Grimes wrote: >> On 2/28/19 10:32 AM, Steve Kargl wrote: > ( ... trimmed ... ) > >>> The BIOS does have a enable/disable button for virtualization. >>> During the great drm-legacy-kmod event of the last month, enabling >>> virtualization locks up a i386 FreeBSD kernel very quickly. >>> Perhaps, virtualization works under amd64. Guess I'll burn >>> an image onto a memstick an d give it a whirl. >> >> bhyve is definitely amd64-only. We don't have any support for bhyve on i386 >> kernels and likely never will. However, if an i386 chroot works, it's >> probably >> faster than an i386 VM anyway. > > bhyve/vmm.ko does not come into play here at all, the real question > is why does our i386 kernel "lock up" simply because a newer CPU > feature appears, it should not do that, as far as I am aware turing > VT-x on does not or should not in anyway change the "i386" behavior > or a machine. What am I missing? I think we don't know enough about this bug report to know what causes the hang. However, an amd64 kernel is going to be a more stable, better supported kernel for running i386 binaries than an i386 kernel at this point, and that will become even more true in the future. >>> >>> This is interesting as well. Does this mean that amd64 is now >>> the only tier 1 platform and all other architectures are after >>> thoughts? >> >> i386 is still marked as tier 1. However, it's becoming increasingly harder >> to >> maintain that level of support for the kernel. core@ is currently exploring >> some ideas about how to make our tiering for i386 more closely reflect what >> we >> as a project are able to provide. Originally we were considering a proposal >> to >> demote all of i386 to tier 2, but after some initial conversations we think a >> better model is to keep the i386 user ABI as tier 1 and only demote the i386 >> kernel. However, we still need to think about what that looks like and >> update >> our tiering language to reflect what that looks like. I think the short >> version >> is that we might no longer guarantee i386-specific fixes for kernel SAs, but >> there are probably additional wrinkles that will arise as that is fleshed out >> further. > > Is core talking to the stake holders about this issue? IMHO this topic > should be an open discussion some place with all parties involved, not > just core deciding what is or is not a tier 1 and/or how to fix our > tier 1 situation with i386 (which I do agree needs to change, but > to what I have not a solid idea.) As you are well aware, core@ has talked to some stakeholders already (including you) which has already resulted in some changes to what core@ is considering to propose to developers. However, it is ultimately core@ who makes tiering decisions. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On Thu, 28 Feb 2019 at 14:13, Ian Lepore wrote: > > I have been of the opinion that armv[67] has met all the bullet points > to be a tier-1 arch for several years, but nobody seemed interested in > declaring it so. Now it'll never happen, because there seems to be > growing momentum to throw everything 32-bit under the bus and declare > freebsd to be a 64-bit-only OS. Netflix wins; those of us building > smaller embedded products will eventually be forced to move to linux. I don't think this is the case. For one example, see the effort kib@ has been putting in (under Foundation sponsorship) on FreeBSD/i386. One of my co-op students this term is working on building out our hardware continuous integration testbed, including 32-bit Arm targets like the BeagleBone Black. Now, i386 has not been our primary reference platform for some time, and I expect that for 32-bit ports FreeBSD will largely be cross-built from amd64, arm64, or powerpc64 hosts. I think this is absolutely fine, and we can still support 32-bit devices well, but our current tier definitions don't fit this model well. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
> On Thu, Feb 28, 2019 at 12:46 PM John Baldwin wrote: > > > On 2/28/19 11:14 AM, Cy Schubert wrote: > > > On February 28, 2019 11:06:46 AM PST, Conrad Meyer > > wrote: > > >> On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl > > >> wrote: > > >>> This is interesting as well. Does this mean that amd64 is now > > >>> the only tier 1 platform and all other architectures are after > > >>> thoughts? > > >> > > >> This has been the de facto truth for years. i386 is mostly only > > >> supported by virtue of sharing code with amd64. There are efforts to > > >> promote arm64 to Tier 1, but it isn't there yet. Power8+ might be > > >> another good alternative Tier 1 candidate eventually. None have > > >> anything like the developer popularity that amd64 enjoys. > > >> > > >> Conrad > > >> ___ > > >> freebsd-current@freebsd.org mailing list > > >> https://lists.freebsd.org/mailman/listinfo/freebsd-current > > >> To unsubscribe, send any mail to > > >> "freebsd-current-unsubscr...@freebsd.org" > > > > > > We deprecated and removed support for 386 and 486 processors. We should > > consider removing support for low end Pentium as well. I'm specifically > > thinking of removing the workarounds like F00F. Are there any processors > > that are still vulnerable to this? > > > > We have only removed support for 386 since it didn't support cmpxchg. We > > still > > nominally support 486s. I don't know how well FreeBSD 13 would run on a > > 486, but > > in theory the code is still there and the binaries shouldn't die with > > illegal > > instruction faults. > > > > The biggest barrier to running on a real 486 is that it's hard for FreeBSD > to fit into 32MB that was the maximum config you could have. You can barely > boot it w/o tuning, though it will still fit a few jobs if you are looking > at something super low-end with a lot of effort. Effort that has been completed in several places, wifi-build for one, where I did boot a 12.0 image of 8MB in size running in 32MB iirc on a D-Link DIR-855? router. > There are a few later CPUs built on basically a 486 whose chipsets could > support up to 128MB or 256MB which is enough to run FreeBSD still. Amd Geode would be in that group? -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
> On 2/28/19 11:14 AM, Cy Schubert wrote: > > On February 28, 2019 11:06:46 AM PST, Conrad Meyer wrote: > >> On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl > >> wrote: > >>> This is interesting as well. Does this mean that amd64 is now > >>> the only tier 1 platform and all other architectures are after > >>> thoughts? > >> > >> This has been the de facto truth for years. i386 is mostly only > >> supported by virtue of sharing code with amd64. There are efforts to > >> promote arm64 to Tier 1, but it isn't there yet. Power8+ might be > >> another good alternative Tier 1 candidate eventually. None have > >> anything like the developer popularity that amd64 enjoys. > >> > >> Conrad > >> ___ > >> freebsd-current@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to > >> "freebsd-current-unsubscr...@freebsd.org" > > > > We deprecated and removed support for 386 and 486 processors. We should > > consider removing support for low end Pentium as well. I'm specifically > > thinking of removing the workarounds like F00F. Are there any processors > > that are still vulnerable to this? > > We have only removed support for 386 since it didn't support cmpxchg. We > still > nominally support 486s. I don't know how well FreeBSD 13 would run on a 486, > but > in theory the code is still there and the binaries shouldn't die with illegal > instruction faults. I know I can still boot FreeBSD 12, diskless no less, on a Transmeta Crusoe TM-5800. I'll go digging for a 486 and confirm or deny if we can boot ^head on it. -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
> On 2/28/19 10:32 AM, Steve Kargl wrote: ( ... trimmed ... ) > > The BIOS does have a enable/disable button for virtualization. > > During the great drm-legacy-kmod event of the last month, enabling > > virtualization locks up a i386 FreeBSD kernel very quickly. > > Perhaps, virtualization works under amd64. Guess I'll burn > > an image onto a memstick an d give it a whirl. > > bhyve is definitely amd64-only. We don't have any support for bhyve on i386 > kernels and likely never will. However, if an i386 chroot works, it's > probably > faster than an i386 VM anyway. bhyve/vmm.ko does not come into play here at all, the real question is why does our i386 kernel "lock up" simply because a newer CPU feature appears, it should not do that, as far as I am aware turing VT-x on does not or should not in anyway change the "i386" behavior or a machine. What am I missing? > >> However, an amd64 kernel is going to be a more stable, better > >> supported kernel for running i386 binaries than an i386 kernel > >> at this point, and that will become even more true in the future. > > > > This is interesting as well. Does this mean that amd64 is now > > the only tier 1 platform and all other architectures are after > > thoughts? > > i386 is still marked as tier 1. However, it's becoming increasingly harder to > maintain that level of support for the kernel. core@ is currently exploring > some ideas about how to make our tiering for i386 more closely reflect what we > as a project are able to provide. Originally we were considering a proposal > to > demote all of i386 to tier 2, but after some initial conversations we think a > better model is to keep the i386 user ABI as tier 1 and only demote the i386 > kernel. However, we still need to think about what that looks like and update > our tiering language to reflect what that looks like. I think the short > version > is that we might no longer guarantee i386-specific fixes for kernel SAs, but > there are probably additional wrinkles that will arise as that is fleshed out > further. Is core talking to the stake holders about this issue? IMHO this topic should be an open discussion some place with all parties involved, not just core deciding what is or is not a tier 1 and/or how to fix our tier 1 situation with i386 (which I do agree needs to change, but to what I have not a solid idea.) -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On 2/28/19 11:24 AM, Cy Schubert wrote: > On February 28, 2019 11:21:24 AM PST, Steve Kargl > wrote: >> On Thu, Feb 28, 2019 at 11:14:51AM -0800, Cy Schubert wrote: >>> On February 28, 2019 11:06:46 AM PST, Conrad Meyer >> wrote: On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl wrote: > This is interesting as well. Does this mean that amd64 is now > the only tier 1 platform and all other architectures are after > thoughts? This has been the de facto truth for years. i386 is mostly only supported by virtue of sharing code with amd64. There are efforts >> to promote arm64 to Tier 1, but it isn't there yet. Power8+ might be another good alternative Tier 1 candidate eventually. None have anything like the developer popularity that amd64 enjoys. >>> >>> We deprecated and removed support for 386 and 486 processors. We >> should consider removing support for low end Pentium as well. I'm >> specifically thinking of removing the workarounds like F00F. Are there >> any processors that are still vulnerable to this? >>> >> >> Ahem, sys/i386/conf/GENERIC contains "cpu I486_CPU". >> Is that a typo? > > I stand corrected. We should remove that. No, it doesn't need removing per my other mail. While there is some cruft in a few files for older CPUs (mostly just initcpu.c and identcpu.c) it is quite small and in code that doesn't change. To effect any type of substantial "win" in reducing code complexity for i386, you'd have to do something like require PAE (so that the kernel could assume PAE instead of a bunch of runtime checks as it does now). That would also give you working 64-bit atomics on i386. However, removing I486_CPU alone doesn't buy you anything. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On February 28, 2019 11:21:24 AM PST, Steve Kargl wrote: >On Thu, Feb 28, 2019 at 11:14:51AM -0800, Cy Schubert wrote: >> On February 28, 2019 11:06:46 AM PST, Conrad Meyer >wrote: >> >On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl >> > wrote: >> >> This is interesting as well. Does this mean that amd64 is now >> >> the only tier 1 platform and all other architectures are after >> >> thoughts? >> > >> >This has been the de facto truth for years. i386 is mostly only >> >supported by virtue of sharing code with amd64. There are efforts >to >> >promote arm64 to Tier 1, but it isn't there yet. Power8+ might be >> >another good alternative Tier 1 candidate eventually. None have >> >anything like the developer popularity that amd64 enjoys. >> > >> >> We deprecated and removed support for 386 and 486 processors. We >should consider removing support for low end Pentium as well. I'm >specifically thinking of removing the workarounds like F00F. Are there >any processors that are still vulnerable to this? >> > >Ahem, sys/i386/conf/GENERIC contains "cpu I486_CPU". >Is that a typo? I stand corrected. We should remove that. -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On Thu, Feb 28, 2019 at 12:14 PM Ian Lepore wrote: > On Thu, 2019-02-28 at 11:06 -0800, Conrad Meyer wrote: > > On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl > > wrote: > > > This is interesting as well. Does this mean that amd64 is now > > > the only tier 1 platform and all other architectures are after > > > thoughts? > > > > This has been the de facto truth for years. i386 is mostly only > > supported by virtue of sharing code with amd64. There are efforts to > > promote arm64 to Tier 1, but it isn't there yet. Power8+ might be > > another good alternative Tier 1 candidate eventually. None have > > anything like the developer popularity that amd64 enjoys. > > > > > > I have been of the opinion that armv[67] has met all the bullet points > to be a tier-1 arch for several years, but nobody seemed interested in > declaring it so. I concur that armv[67] is the closest thing we have to a second tier 1. arm64 is also quite good, but still has a few more rough edges compared to armv[67]. > Now it'll never happen, because there seems to be > growing momentum to throw everything 32-bit under the bus and declare > freebsd to be a 64-bit-only OS. Netflix wins; those of us building > smaller embedded products will eventually be forced to move to linux. > While there's been some talk, there's too many relevant 32-bit arm chips to toss it out in 13 (planned in 2ish years or 2021) and no i386 in 13 likely would be a stretch as well, so 13 almost certainly will have 32-bit kernels and userland support (though that will require the 32-bit processors support 64-bit atomics to reduce friction). Who know if that will be the case in 4 or 5 years when 14 is branched (so ~2025). Current trends suggest that 32-bits might not be relevant then, but we certainly can't say that for sure today. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On Thu, Feb 28, 2019 at 12:46 PM John Baldwin wrote: > On 2/28/19 11:14 AM, Cy Schubert wrote: > > On February 28, 2019 11:06:46 AM PST, Conrad Meyer > wrote: > >> On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl > >> wrote: > >>> This is interesting as well. Does this mean that amd64 is now > >>> the only tier 1 platform and all other architectures are after > >>> thoughts? > >> > >> This has been the de facto truth for years. i386 is mostly only > >> supported by virtue of sharing code with amd64. There are efforts to > >> promote arm64 to Tier 1, but it isn't there yet. Power8+ might be > >> another good alternative Tier 1 candidate eventually. None have > >> anything like the developer popularity that amd64 enjoys. > >> > >> Conrad > >> ___ > >> freebsd-current@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to > >> "freebsd-current-unsubscr...@freebsd.org" > > > > We deprecated and removed support for 386 and 486 processors. We should > consider removing support for low end Pentium as well. I'm specifically > thinking of removing the workarounds like F00F. Are there any processors > that are still vulnerable to this? > > We have only removed support for 386 since it didn't support cmpxchg. We > still > nominally support 486s. I don't know how well FreeBSD 13 would run on a > 486, but > in theory the code is still there and the binaries shouldn't die with > illegal > instruction faults. > The biggest barrier to running on a real 486 is that it's hard for FreeBSD to fit into 32MB that was the maximum config you could have. You can barely boot it w/o tuning, though it will still fit a few jobs if you are looking at something super low-end with a lot of effort. There are a few later CPUs built on basically a 486 whose chipsets could support up to 128MB or 256MB which is enough to run FreeBSD still. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On 2/28/19 11:14 AM, Cy Schubert wrote: > On February 28, 2019 11:06:46 AM PST, Conrad Meyer wrote: >> On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl >> wrote: >>> This is interesting as well. Does this mean that amd64 is now >>> the only tier 1 platform and all other architectures are after >>> thoughts? >> >> This has been the de facto truth for years. i386 is mostly only >> supported by virtue of sharing code with amd64. There are efforts to >> promote arm64 to Tier 1, but it isn't there yet. Power8+ might be >> another good alternative Tier 1 candidate eventually. None have >> anything like the developer popularity that amd64 enjoys. >> >> Conrad >> ___ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscr...@freebsd.org" > > We deprecated and removed support for 386 and 486 processors. We should > consider removing support for low end Pentium as well. I'm specifically > thinking of removing the workarounds like F00F. Are there any processors that > are still vulnerable to this? We have only removed support for 386 since it didn't support cmpxchg. We still nominally support 486s. I don't know how well FreeBSD 13 would run on a 486, but in theory the code is still there and the binaries shouldn't die with illegal instruction faults. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On 2/28/19 10:32 AM, Steve Kargl wrote: > On Thu, Feb 28, 2019 at 09:09:38AM -0800, John Baldwin wrote: >> You can do all your tests directly on amd64 by just adding >> "-m32" to compile i386 binaries against the libraries in /usr/lib32 >> and you will generate the same i386 binaries as if you were building >> on an i386 system. If you are a bit more paranoid, you can install >> an i386 world and chroot into it and use that to test i386. I do this >> myself (-m32) for testing i386 things. I also run i386 VMs under >> bhyve on amd64 hosts. I'm not sure your laptop's CPU can run i386 >> VMs though, and you don't need a VM to test userland-only changes >> (I'm usually trying to test kernel changes). > > Interesting. Did not know I could use -m32 with any reliability. > Setting up my testing environment may be a challenge as I use > mpfr/gmp, so would need -m32 aware versions of those libraries. > I normally install whatever the port collection offers for mpfr/gmp. > I suppose I would need to install those independently to get > multilib support. I would also need to compile 2 versions of my > testing framework (ie., additional support library). -m32 didn't used to work in early amd64 (like 6.x or maybe 7.x), but it has worked reliably for several branches now. That said, if you want to use i386 packages, I think a chroot is probably a safer route as in the chroot you can use pkg to install i386 packages just as if it was an i386 machine. > The BIOS does have a enable/disable button for virtualization. > During the great drm-legacy-kmod event of the last month, enabling > virtualization locks up a i386 FreeBSD kernel very quickly. > Perhaps, virtualization works under amd64. Guess I'll burn > an image onto a memstick an d give it a whirl. bhyve is definitely amd64-only. We don't have any support for bhyve on i386 kernels and likely never will. However, if an i386 chroot works, it's probably faster than an i386 VM anyway. >> However, an amd64 kernel is going to be a more stable, better >> supported kernel for running i386 binaries than an i386 kernel >> at this point, and that will become even more true in the future. > > This is interesting as well. Does this mean that amd64 is now > the only tier 1 platform and all other architectures are after > thoughts? i386 is still marked as tier 1. However, it's becoming increasingly harder to maintain that level of support for the kernel. core@ is currently exploring some ideas about how to make our tiering for i386 more closely reflect what we as a project are able to provide. Originally we were considering a proposal to demote all of i386 to tier 2, but after some initial conversations we think a better model is to keep the i386 user ABI as tier 1 and only demote the i386 kernel. However, we still need to think about what that looks like and update our tiering language to reflect what that looks like. I think the short version is that we might no longer guarantee i386-specific fixes for kernel SAs, but there are probably additional wrinkles that will arise as that is fleshed out further. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On Thu, Feb 28, 2019 at 11:14:51AM -0800, Cy Schubert wrote: > On February 28, 2019 11:06:46 AM PST, Conrad Meyer wrote: > >On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl > > wrote: > >> This is interesting as well. Does this mean that amd64 is now > >> the only tier 1 platform and all other architectures are after > >> thoughts? > > > >This has been the de facto truth for years. i386 is mostly only > >supported by virtue of sharing code with amd64. There are efforts to > >promote arm64 to Tier 1, but it isn't there yet. Power8+ might be > >another good alternative Tier 1 candidate eventually. None have > >anything like the developer popularity that amd64 enjoys. > > > > We deprecated and removed support for 386 and 486 processors. We should > consider removing support for low end Pentium as well. I'm specifically > thinking of removing the workarounds like F00F. Are there any processors that > are still vulnerable to this? > Ahem, sys/i386/conf/GENERIC contains "cpu I486_CPU". Is that a typo? -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On February 28, 2019 11:06:46 AM PST, Conrad Meyer wrote: >On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl > wrote: >> This is interesting as well. Does this mean that amd64 is now >> the only tier 1 platform and all other architectures are after >> thoughts? > >This has been the de facto truth for years. i386 is mostly only >supported by virtue of sharing code with amd64. There are efforts to >promote arm64 to Tier 1, but it isn't there yet. Power8+ might be >another good alternative Tier 1 candidate eventually. None have >anything like the developer popularity that amd64 enjoys. > >Conrad >___ >freebsd-current@freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to >"freebsd-current-unsubscr...@freebsd.org" We deprecated and removed support for 386 and 486 processors. We should consider removing support for low end Pentium as well. I'm specifically thinking of removing the workarounds like F00F. Are there any processors that are still vulnerable to this? -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On Thu, 2019-02-28 at 11:06 -0800, Conrad Meyer wrote: > On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl > wrote: > > This is interesting as well. Does this mean that amd64 is now > > the only tier 1 platform and all other architectures are after > > thoughts? > > This has been the de facto truth for years. i386 is mostly only > supported by virtue of sharing code with amd64. There are efforts to > promote arm64 to Tier 1, but it isn't there yet. Power8+ might be > another good alternative Tier 1 candidate eventually. None have > anything like the developer popularity that amd64 enjoys. > > I have been of the opinion that armv[67] has met all the bullet points to be a tier-1 arch for several years, but nobody seemed interested in declaring it so. Now it'll never happen, because there seems to be growing momentum to throw everything 32-bit under the bus and declare freebsd to be a 64-bit-only OS. Netflix wins; those of us building smaller embedded products will eventually be forced to move to linux. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl wrote: > This is interesting as well. Does this mean that amd64 is now > the only tier 1 platform and all other architectures are after > thoughts? This has been the de facto truth for years. i386 is mostly only supported by virtue of sharing code with amd64. There are efforts to promote arm64 to Tier 1, but it isn't there yet. Power8+ might be another good alternative Tier 1 candidate eventually. None have anything like the developer popularity that amd64 enjoys. Conrad ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On Thu, Feb 28, 2019 at 09:09:38AM -0800, John Baldwin wrote:
> On 2/23/19 8:39 AM, Steve Kargl wrote:
> > On Sat, Feb 23, 2019 at 08:32:23AM -0800, Conrad Meyer wrote:
> >> On Sat, Feb 23, 2019 at 12:44 AM Steve Kargl
> >> wrote:
> >>> Ideas?
> >>> ...
> >>> +CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz
> >>> 686-class CPU)
> >>>Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13
> >>
> >> https://ark.intel.com/content/www/us/en/ark/products/31728/intel-core-2-duo-processor-t7250-2m-cache-2-00-ghz-800-mhz-fsb.html
> >>
> >>> Intel® Virtualization Technology (VT-x) ‡ Yes
> >>> Intel® 64 ‡ Yes
> >>
> >>> Merom is the first Intel mobile processor to feature Intel 64
> >>> architecture.
> >>
> >> So, as a workaround, maybe run amd64?
> >
> > This is the only i386 FreeBSD system that I have. This
> > is the system where all the libm changes I've made have
> > been tested. i386 floating point is different than
> > amd64 floating point. See npx.c and the history of any
> > of the long double functions that I've worked on. If
> > this laptop does not run i386, there will be no testing
> > of libm changes on the architecture.
>
> Yes, but we set the initial FPU control word for 32-bit binaries
> to match i386 when running i386 binaries under an amd64 kernel.
>
> See these comments in sys/x86/include/fpu.h with which you are
> likely familiar:
>
> /*
> * The hardware default control word for i387's and later coprocessors is
> * 0x37F, giving:
> *
> *round to nearest
> *64-bit precision
> *all exceptions masked.
> *
> * FreeBSD/i386 uses 53 bit precision for things like fadd/fsub/fsqrt etc
> * because of the difference between memory and fpu register stack arguments.
> * If its using an intermediate fpu register, it has 80/64 bits to work
> * with. If it uses memory, it has 64/53 bits to work with. However,
> * gcc is aware of this and goes to a fair bit of trouble to make the
> * best use of it.
> *
> * This is mostly academic for AMD64, because the ABI prefers the use
> * SSE2 based math. For FreeBSD/amd64, we go with the default settings.
> */
> #define __INITIAL_FPUCW__ 0x037F
> #define __INITIAL_FPUCW_I386__ 0x127F
> #define __INITIAL_NPXCW__ __INITIAL_FPUCW_I386__
> #define __INITIAL_MXCSR__ 0x1F80
> #define __INITIAL_MXCSR_MASK__ 0xFFBF
>
> And this code in ia32_setregs() in sys/amd64/ia32/ia32_signal.c
> to set the initial register values for i386 processes:
>
> /*
> * Clear registers on exec
> */
> void
> ia32_setregs(struct thread *td, struct image_params *imgp, u_long stack)
> {
> ...
> pcb->pcb_initial_fpucw = __INITIAL_FPUCW_I386__;
> ...
> }
>
> This matches what exec_setregs() in sys/i386/i386/machdep.c does:
>
> /*
> * Reset registers to default values on exec.
> */
> void
> exec_setregs(struct thread *td, struct image_params *imgp, u_long stack)
> {
> ...
> pcb->pcb_initial_npxcw = __INITIAL_NPXCW__;
> ...
> }
>
> You can do all your tests directly on amd64 by just adding
> "-m32" to compile i386 binaries against the libraries in /usr/lib32
> and you will generate the same i386 binaries as if you were building
> on an i386 system. If you are a bit more paranoid, you can install
> an i386 world and chroot into it and use that to test i386. I do this
> myself (-m32) for testing i386 things. I also run i386 VMs under
> bhyve on amd64 hosts. I'm not sure your laptop's CPU can run i386
> VMs though, and you don't need a VM to test userland-only changes
> (I'm usually trying to test kernel changes).
Interesting. Did not know I could use -m32 with any reliability.
Setting up my testing environment may be a challenge as I use
mpfr/gmp, so would need -m32 aware versions of those libraries.
I normally install whatever the port collection offers for mpfr/gmp.
I suppose I would need to install those independently to get
multilib support. I would also need to compile 2 versions of my
testing framework (ie., additional support library).
The BIOS does have a enable/disable button for virtualization.
During the great drm-legacy-kmod event of the last month, enabling
virtualization locks up a i386 FreeBSD kernel very quickly.
Perhaps, virtualization works under amd64. Guess I'll burn
an image onto a memstick an d give it a whirl.
> However, an amd64 kernel is going to be a more stable, better
> supported kernel for running i386 binaries than an i386 kernel
> at this point, and that will become even more true in the future.
This is interesting as well. Does this mean that amd64 is now
the only tier 1 platform and all other architectures are after
thoughts?
--
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On 2/23/19 8:39 AM, Steve Kargl wrote:
> On Sat, Feb 23, 2019 at 08:32:23AM -0800, Conrad Meyer wrote:
>> On Sat, Feb 23, 2019 at 12:44 AM Steve Kargl
>> wrote:
>>> Ideas?
>>> ...
>>> +CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz
>>> 686-class CPU)
>>>Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13
>>
>> https://ark.intel.com/content/www/us/en/ark/products/31728/intel-core-2-duo-processor-t7250-2m-cache-2-00-ghz-800-mhz-fsb.html
>>
>>> Intel® Virtualization Technology (VT-x) ‡ Yes
>>> Intel® 64 ‡ Yes
>>
>>> Merom is the first Intel mobile processor to feature Intel 64 architecture.
>>
>> So, as a workaround, maybe run amd64?
>
> This is the only i386 FreeBSD system that I have. This
> is the system where all the libm changes I've made have
> been tested. i386 floating point is different than
> amd64 floating point. See npx.c and the history of any
> of the long double functions that I've worked on. If
> this laptop does not run i386, there will be no testing
> of libm changes on the architecture.
Yes, but we set the initial FPU control word for 32-bit binaries to match i386
when
running i386 binaries under an amd64 kernel.
See these comments in sys/x86/include/fpu.h with which you are likely familiar:
/*
* The hardware default control word for i387's and later coprocessors is
* 0x37F, giving:
*
* round to nearest
* 64-bit precision
* all exceptions masked.
*
* FreeBSD/i386 uses 53 bit precision for things like fadd/fsub/fsqrt etc
* because of the difference between memory and fpu register stack arguments.
* If its using an intermediate fpu register, it has 80/64 bits to work
* with. If it uses memory, it has 64/53 bits to work with. However,
* gcc is aware of this and goes to a fair bit of trouble to make the
* best use of it.
*
* This is mostly academic for AMD64, because the ABI prefers the use
* SSE2 based math. For FreeBSD/amd64, we go with the default settings.
*/
#define __INITIAL_FPUCW__ 0x037F
#define __INITIAL_FPUCW_I386__ 0x127F
#define __INITIAL_NPXCW__ __INITIAL_FPUCW_I386__
#define __INITIAL_MXCSR__ 0x1F80
#define __INITIAL_MXCSR_MASK__ 0xFFBF
And this code in ia32_setregs() in sys/amd64/ia32/ia32_signal.c to set the
initial register values for i386 processes:
/*
* Clear registers on exec
*/
void
ia32_setregs(struct thread *td, struct image_params *imgp, u_long stack)
{
...
pcb->pcb_initial_fpucw = __INITIAL_FPUCW_I386__;
...
}
This matches what exec_setregs() in sys/i386/i386/machdep.c does:
/*
* Reset registers to default values on exec.
*/
void
exec_setregs(struct thread *td, struct image_params *imgp, u_long stack)
{
...
pcb->pcb_initial_npxcw = __INITIAL_NPXCW__;
...
}
You can do all your tests directly on amd64 by just adding "-m32" to compile
i386
binaries against the libraries in /usr/lib32 and you will generate the same i386
binaries as if you were building on an i386 system. If you are a bit more
paranoid,
you can install an i386 world and chroot into it and use that to test i386. I
do
this myself (-m32) for testing i386 things. I also run i386 VMs under bhyve on
amd64 hosts. I'm not sure your laptop's CPU can run i386 VMs though, and you
don't
need a VM to test userland-only changes (I'm usually trying to test kernel
changes).
However, an amd64 kernel is going to be a more stable, better supported kernel
for
running i386 binaries than an i386 kernel at this point, and that will become
even
more true in the future.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On Sun, Feb 24, 2019 at 10:27:26AM +0100, Tijl Coosemans wrote: > On Sat, 23 Feb 2019 17:28:51 -0800 Steve Kargl > wrote: > > On Sat, Feb 23, 2019 at 12:03:58PM -0700, Warner Losh wrote: > >> On Sat, Feb 23, 2019 at 10:57 AM Steve Kargl > >> wrote: > >>> Supposely, the laptop only has 4 GB of memory. Not sure how > >>> it finds memory above 4 GB. > >> > >> Some older chipsets had a 'hole' in memory that they mapped the PCI bus > >> into and then remapped RAM in that range up above the 4GB boundary. That's > >> how it can find memory above 4GB when you have only 4GB of RAM. I hit it > >> with the PC Card stuff I did back in the day since it broke certain > >> heuristics I had in the code that turned out to be unwise for many reasons > >> (not just this one). I don't recall all the details, since it's been so > >> long ago. > >> > >> So I think kib@ is right when he highlights > >>> +0x0001 - 0x00011ffe7fff, 536772608 bytes (131048 pages) > >> > >> as the memory, since this is indeed above the 4GB limit. It's about 128k > >> of 4k pages (just shy of the 131072 I'd expect), which is a surprisingly > >> round number. Also one that's easy to implement in hardware. So it > >> certainly "smells" the same... > >> > >> That's why I agree with others that hw.above4g_allow=0 is worth a shot, for > >> at least diagnostic purposes. This memory wasn't used before and if it's > >> used now by the drm drivers, and those aren't PAE safe (meaning they cope > >> with allocations beyond 4GB), then that's quite useful to know. Or maybe > >> it's a different driver hating things and stomping on video memory due to > >> wrap around. > > > > Thanks for the explanation. Here's an update. TL;DR: xorg is > > up and running; drm-legacy-kmod seems to be unsafe/unaware of > > PAE. > > > > Build world/kernel, drm-legacy-kmod, minimum needed ports for xorg. > > Kernel is unmodified GENERIC. > > > > Reboot without setting anything in /boot/loader.conf > > > > % sysctl -a | grep above > > % sysctl -a | grep pae > > vm.pmap.pae_mode: 1 > > % kldload /boot/modules/i915kms.ko > > > > Black screen of death. Did not even get to running xinit. > > > > Hard reset to single user mode. > > > > # fsck -y > > # mount -a > > # vi /boot/loader.conf. > > (Add hw.above4g_allow=0) > > # sync > > # shutdown -r now > > > > % sysctl -a | grep above > > % sysctl -a | grep pae > > vm.pmap.pae_mode: 1 > > % cat /boot/loader.conf > > if_ath_load="YES" > > if_ath_pci_load="YES" > > cpuctl_load="YES" > > hw.above4g_allow=0 > > % kldload /boot/modules/i915kms.ko > > > > Switch to vt3, login as normal user. > > > > % startx -- -depth 24 >& ~/tmp/.x.out > > > > Xorg is up and running. Not sure why my first attempt at using > > hw.above4g_allow=0 did not work. Perhaps, mismatch between the xorg > > bits and kernel/world bits. > > > > % sysctl -a | grep mem > > vm.lowmem_period: 10 > > vm.kmem_map_free: 1669365760 > > vm.kmem_map_size: 41910272 > > vm.kmem_size_scale: 1 > > vm.kmem_size_max: 1711276032 > > vm.kmem_size_min: 12582912 > > vm.kmem_zmax: 65536 > > vm.kmem_size: 1711276032 > > hw.physmem: 3715489792 > > hw.usermem: 3592175616 > > hw.realmem: 4294963200 > > > > % dmesg | grep memory > > real memory = 4294967296 (4096 MB) > > avail memory = 3637673984 (3469 MB) > > agp0: aperture size is 256M, detected 7676k stolen memory > > > > The pre-r343567 dmesg has > > > > real memory = 4294967296 (4096 MB) > > avail memory = 3639914496 (3471 MB) > > > > I can live with 2 MB loss. > > > > Conclusion, drm-legacy-kmod is not PAE safe/aware. > > > > Probably want to put something in /usr/src about possible > > problems with new pmap.h on i386 FreeBSD. > > Now it would be interesting to do the same tests with drm-current-kmod. Caveats: old laptop and I only rebuilt drm-current-kmod and the gpu-firmware-kmod. drm-current-kmod does not work. The setting of hw.above4g_allow is immaterial. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On Sun, Feb 24, 2019 at 10:58 AM Steve Kargl < s...@troutmask.apl.washington.edu> wrote: > On Sun, Feb 24, 2019 at 10:06:53AM -0700, Warner Losh wrote: > > > > > > > Maybe I missed it, but Steve, did you run the patched in a different way > > tests that I suggested? Replacing the limits with 0x for testing > > purposes to ensure that drm isn't saying it can cope with larger > addresses? > > That might help narrow down what the problem here one more level than > "It's > > PAE". > > > > So, I dug through the code a bit. Niclas changed the port to > use BUS_SPACE_MAXADDR. This is defined in include/x86/bus.h > > #if defined(__amd64__) || defined(PAE) > #define BUS_SPACE_MAXADDR_48BIT 0xULL > #define BUS_SPACE_MAXADDR 0xULL > #else > #define BUS_SPACE_MAXADDR 0x > #endif > > I don't know if defined(PAE) is effected by hw.above4g_allow, > or where it gets defined or if it is defined. > Grepping suggests that PAE isn't defined w/o the option. The option is only in the PAE kernel, so maybe my test wouldn't say anything useful and it's a different issue. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On Sun, Feb 24, 2019 at 10:06:53AM -0700, Warner Losh wrote: > On Sun, Feb 24, 2019 at 2:27 AM Tijl Coosemans wrote: > > > On Sat, 23 Feb 2019 17:28:51 -0800 Steve Kargl > > wrote: > > > On Sat, Feb 23, 2019 at 12:03:58PM -0700, Warner Losh wrote: > > >> On Sat, Feb 23, 2019 at 10:57 AM Steve Kargl > > >> wrote: > > >>> Supposely, the laptop only has 4 GB of memory. Not sure how > > >>> it finds memory above 4 GB. > > >> > > >> Some older chipsets had a 'hole' in memory that they mapped the PCI bus > > >> into and then remapped RAM in that range up above the 4GB boundary. > > That's > > >> how it can find memory above 4GB when you have only 4GB of RAM. I hit it > > >> with the PC Card stuff I did back in the day since it broke certain > > >> heuristics I had in the code that turned out to be unwise for many > > reasons > > >> (not just this one). I don't recall all the details, since it's been so > > >> long ago. > > >> > > >> So I think kib@ is right when he highlights > > >>> +0x0001 - 0x00011ffe7fff, 536772608 bytes (131048 > > pages) > > >> > > >> as the memory, since this is indeed above the 4GB limit. It's about > > 128k > > >> of 4k pages (just shy of the 131072 I'd expect), which is a surprisingly > > >> round number. Also one that's easy to implement in hardware. So it > > >> certainly "smells" the same... > > >> > > >> That's why I agree with others that hw.above4g_allow=0 is worth a shot, > > for > > >> at least diagnostic purposes. This memory wasn't used before and if it's > > >> used now by the drm drivers, and those aren't PAE safe (meaning they > > cope > > >> with allocations beyond 4GB), then that's quite useful to know. Or maybe > > >> it's a different driver hating things and stomping on video memory due > > to > > >> wrap around. > > > > > > Thanks for the explanation. Here's an update. TL;DR: xorg is > > > up and running; drm-legacy-kmod seems to be unsafe/unaware of > > > PAE. > > > > > > Build world/kernel, drm-legacy-kmod, minimum needed ports for xorg. > > > Kernel is unmodified GENERIC. > > > > > > Reboot without setting anything in /boot/loader.conf > > > > > > % sysctl -a | grep above > > > % sysctl -a | grep pae > > > vm.pmap.pae_mode: 1 > > > % kldload /boot/modules/i915kms.ko > > > > > > Black screen of death. Did not even get to running xinit. > > > > > > Hard reset to single user mode. > > > > > > # fsck -y > > > # mount -a > > > # vi /boot/loader.conf. > > > (Add hw.above4g_allow=0) > > > # sync > > > # shutdown -r now > > > > > > % sysctl -a | grep above > > > % sysctl -a | grep pae > > > vm.pmap.pae_mode: 1 > > > % cat /boot/loader.conf > > > if_ath_load="YES" > > > if_ath_pci_load="YES" > > > cpuctl_load="YES" > > > hw.above4g_allow=0 > > > % kldload /boot/modules/i915kms.ko > > > > > > Switch to vt3, login as normal user. > > > > > > % startx -- -depth 24 >& ~/tmp/.x.out > > > > > > Xorg is up and running. Not sure why my first attempt at using > > > hw.above4g_allow=0 did not work. Perhaps, mismatch between the xorg > > > bits and kernel/world bits. > > > > > > % sysctl -a | grep mem > > > vm.lowmem_period: 10 > > > vm.kmem_map_free: 1669365760 > > > vm.kmem_map_size: 41910272 > > > vm.kmem_size_scale: 1 > > > vm.kmem_size_max: 1711276032 > > > vm.kmem_size_min: 12582912 > > > vm.kmem_zmax: 65536 > > > vm.kmem_size: 1711276032 > > > hw.physmem: 3715489792 > > > hw.usermem: 3592175616 > > > hw.realmem: 4294963200 > > > > > > % dmesg | grep memory > > > real memory = 4294967296 (4096 MB) > > > avail memory = 3637673984 (3469 MB) > > > agp0: aperture size is 256M, detected 7676k stolen memory > > > > > > The pre-r343567 dmesg has > > > > > > real memory = 4294967296 (4096 MB) > > > avail memory = 3639914496 (3471 MB) > > > > > > I can live with 2 MB loss. > > > > > > Conclusion, drm-legacy-kmod is not PAE safe/aware. > > > > > > Probably want to put something in /usr/src about possible > > > problems with new pmap.h on i386 FreeBSD. > > > > Now it would be interesting to do the same tests with drm-current-kmod. > > > > Maybe I missed it, but Steve, did you run the patched in a different way > tests that I suggested? Replacing the limits with 0x for testing > purposes to ensure that drm isn't saying it can cope with larger addresses? > That might help narrow down what the problem here one more level than "It's > PAE". > I did try a few patches to the drm-legacy-kmod port when I first found that it would not build, but I honestly don't remember if your suggestion was one of them. I'm testing with the stock port at r492863 | zeising | 2019-02-13 12:52:03 -0800 (Wed, 13 Feb 2019) | 8 lines graphics/drm-legacy-kmod: Update snapshot Update the graphics/drm-legacy-kmod drivers to the latest snapshot. This includes fixes to make the driver build on CURRENT after base r343567. Reported by:Steve Kargl Approved by:jmd (maintainer, implicit) If I do not set hw.above4g_allow to 0, the above port will lock up the syst
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On Sun, Feb 24, 2019 at 10:06:53AM -0700, Warner Losh wrote: > > > > Maybe I missed it, but Steve, did you run the patched in a different way > tests that I suggested? Replacing the limits with 0x for testing > purposes to ensure that drm isn't saying it can cope with larger addresses? > That might help narrow down what the problem here one more level than "It's > PAE". > So, I dug through the code a bit. Niclas changed the port to use BUS_SPACE_MAXADDR. This is defined in include/x86/bus.h #if defined(__amd64__) || defined(PAE) #define BUS_SPACE_MAXADDR_48BIT 0xULL #define BUS_SPACE_MAXADDR 0xULL #else #define BUS_SPACE_MAXADDR 0x #endif I don't know if defined(PAE) is effected by hw.above4g_allow, or where it gets defined or if it is defined. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On Sun, Feb 24, 2019 at 2:27 AM Tijl Coosemans wrote: > On Sat, 23 Feb 2019 17:28:51 -0800 Steve Kargl > wrote: > > On Sat, Feb 23, 2019 at 12:03:58PM -0700, Warner Losh wrote: > >> On Sat, Feb 23, 2019 at 10:57 AM Steve Kargl > >> wrote: > >>> Supposely, the laptop only has 4 GB of memory. Not sure how > >>> it finds memory above 4 GB. > >> > >> Some older chipsets had a 'hole' in memory that they mapped the PCI bus > >> into and then remapped RAM in that range up above the 4GB boundary. > That's > >> how it can find memory above 4GB when you have only 4GB of RAM. I hit it > >> with the PC Card stuff I did back in the day since it broke certain > >> heuristics I had in the code that turned out to be unwise for many > reasons > >> (not just this one). I don't recall all the details, since it's been so > >> long ago. > >> > >> So I think kib@ is right when he highlights > >>> +0x0001 - 0x00011ffe7fff, 536772608 bytes (131048 > pages) > >> > >> as the memory, since this is indeed above the 4GB limit. It's about > 128k > >> of 4k pages (just shy of the 131072 I'd expect), which is a surprisingly > >> round number. Also one that's easy to implement in hardware. So it > >> certainly "smells" the same... > >> > >> That's why I agree with others that hw.above4g_allow=0 is worth a shot, > for > >> at least diagnostic purposes. This memory wasn't used before and if it's > >> used now by the drm drivers, and those aren't PAE safe (meaning they > cope > >> with allocations beyond 4GB), then that's quite useful to know. Or maybe > >> it's a different driver hating things and stomping on video memory due > to > >> wrap around. > > > > Thanks for the explanation. Here's an update. TL;DR: xorg is > > up and running; drm-legacy-kmod seems to be unsafe/unaware of > > PAE. > > > > Build world/kernel, drm-legacy-kmod, minimum needed ports for xorg. > > Kernel is unmodified GENERIC. > > > > Reboot without setting anything in /boot/loader.conf > > > > % sysctl -a | grep above > > % sysctl -a | grep pae > > vm.pmap.pae_mode: 1 > > % kldload /boot/modules/i915kms.ko > > > > Black screen of death. Did not even get to running xinit. > > > > Hard reset to single user mode. > > > > # fsck -y > > # mount -a > > # vi /boot/loader.conf. > > (Add hw.above4g_allow=0) > > # sync > > # shutdown -r now > > > > % sysctl -a | grep above > > % sysctl -a | grep pae > > vm.pmap.pae_mode: 1 > > % cat /boot/loader.conf > > if_ath_load="YES" > > if_ath_pci_load="YES" > > cpuctl_load="YES" > > hw.above4g_allow=0 > > % kldload /boot/modules/i915kms.ko > > > > Switch to vt3, login as normal user. > > > > % startx -- -depth 24 >& ~/tmp/.x.out > > > > Xorg is up and running. Not sure why my first attempt at using > > hw.above4g_allow=0 did not work. Perhaps, mismatch between the xorg > > bits and kernel/world bits. > > > > % sysctl -a | grep mem > > vm.lowmem_period: 10 > > vm.kmem_map_free: 1669365760 > > vm.kmem_map_size: 41910272 > > vm.kmem_size_scale: 1 > > vm.kmem_size_max: 1711276032 > > vm.kmem_size_min: 12582912 > > vm.kmem_zmax: 65536 > > vm.kmem_size: 1711276032 > > hw.physmem: 3715489792 > > hw.usermem: 3592175616 > > hw.realmem: 4294963200 > > > > % dmesg | grep memory > > real memory = 4294967296 (4096 MB) > > avail memory = 3637673984 (3469 MB) > > agp0: aperture size is 256M, detected 7676k stolen memory > > > > The pre-r343567 dmesg has > > > > real memory = 4294967296 (4096 MB) > > avail memory = 3639914496 (3471 MB) > > > > I can live with 2 MB loss. > > > > Conclusion, drm-legacy-kmod is not PAE safe/aware. > > > > Probably want to put something in /usr/src about possible > > problems with new pmap.h on i386 FreeBSD. > > Now it would be interesting to do the same tests with drm-current-kmod. > Maybe I missed it, but Steve, did you run the patched in a different way tests that I suggested? Replacing the limits with 0x for testing purposes to ensure that drm isn't saying it can cope with larger addresses? That might help narrow down what the problem here one more level than "It's PAE". Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On Sat, 23 Feb 2019 17:28:51 -0800 Steve Kargl wrote: > On Sat, Feb 23, 2019 at 12:03:58PM -0700, Warner Losh wrote: >> On Sat, Feb 23, 2019 at 10:57 AM Steve Kargl >> wrote: >>> Supposely, the laptop only has 4 GB of memory. Not sure how >>> it finds memory above 4 GB. >> >> Some older chipsets had a 'hole' in memory that they mapped the PCI bus >> into and then remapped RAM in that range up above the 4GB boundary. That's >> how it can find memory above 4GB when you have only 4GB of RAM. I hit it >> with the PC Card stuff I did back in the day since it broke certain >> heuristics I had in the code that turned out to be unwise for many reasons >> (not just this one). I don't recall all the details, since it's been so >> long ago. >> >> So I think kib@ is right when he highlights >>> +0x0001 - 0x00011ffe7fff, 536772608 bytes (131048 pages) >> >> as the memory, since this is indeed above the 4GB limit. It's about 128k >> of 4k pages (just shy of the 131072 I'd expect), which is a surprisingly >> round number. Also one that's easy to implement in hardware. So it >> certainly "smells" the same... >> >> That's why I agree with others that hw.above4g_allow=0 is worth a shot, for >> at least diagnostic purposes. This memory wasn't used before and if it's >> used now by the drm drivers, and those aren't PAE safe (meaning they cope >> with allocations beyond 4GB), then that's quite useful to know. Or maybe >> it's a different driver hating things and stomping on video memory due to >> wrap around. > > Thanks for the explanation. Here's an update. TL;DR: xorg is > up and running; drm-legacy-kmod seems to be unsafe/unaware of > PAE. > > Build world/kernel, drm-legacy-kmod, minimum needed ports for xorg. > Kernel is unmodified GENERIC. > > Reboot without setting anything in /boot/loader.conf > > % sysctl -a | grep above > % sysctl -a | grep pae > vm.pmap.pae_mode: 1 > % kldload /boot/modules/i915kms.ko > > Black screen of death. Did not even get to running xinit. > > Hard reset to single user mode. > > # fsck -y > # mount -a > # vi /boot/loader.conf. > (Add hw.above4g_allow=0) > # sync > # shutdown -r now > > % sysctl -a | grep above > % sysctl -a | grep pae > vm.pmap.pae_mode: 1 > % cat /boot/loader.conf > if_ath_load="YES" > if_ath_pci_load="YES" > cpuctl_load="YES" > hw.above4g_allow=0 > % kldload /boot/modules/i915kms.ko > > Switch to vt3, login as normal user. > > % startx -- -depth 24 >& ~/tmp/.x.out > > Xorg is up and running. Not sure why my first attempt at using > hw.above4g_allow=0 did not work. Perhaps, mismatch between the xorg > bits and kernel/world bits. > > % sysctl -a | grep mem > vm.lowmem_period: 10 > vm.kmem_map_free: 1669365760 > vm.kmem_map_size: 41910272 > vm.kmem_size_scale: 1 > vm.kmem_size_max: 1711276032 > vm.kmem_size_min: 12582912 > vm.kmem_zmax: 65536 > vm.kmem_size: 1711276032 > hw.physmem: 3715489792 > hw.usermem: 3592175616 > hw.realmem: 4294963200 > > % dmesg | grep memory > real memory = 4294967296 (4096 MB) > avail memory = 3637673984 (3469 MB) > agp0: aperture size is 256M, detected 7676k stolen memory > > The pre-r343567 dmesg has > > real memory = 4294967296 (4096 MB) > avail memory = 3639914496 (3471 MB) > > I can live with 2 MB loss. > > Conclusion, drm-legacy-kmod is not PAE safe/aware. > > Probably want to put something in /usr/src about possible > problems with new pmap.h on i386 FreeBSD. Now it would be interesting to do the same tests with drm-current-kmod. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On Sat, Feb 23, 2019 at 12:03:58PM -0700, Warner Losh wrote: > On Sat, Feb 23, 2019 at 10:57 AM Steve Kargl < > s...@troutmask.apl.washington.edu> wrote: > > > Supposely, the laptop only has 4 GB of memory. Not sure how > > it finds memory above 4 GB. > > > > Some older chipsets had a 'hole' in memory that they mapped the PCI bus > into and then remapped RAM in that range up above the 4GB boundary. That's > how it can find memory above 4GB when you have only 4GB of RAM. I hit it > with the PC Card stuff I did back in the day since it broke certain > heuristics I had in the code that turned out to be unwise for many reasons > (not just this one). I don't recall all the details, since it's been so > long ago. > > So I think kib@ is right when he highlights > > +0x0001 - 0x00011ffe7fff, 536772608 bytes (131048 pages) > > as the memory, since this is indeed above the 4GB limit. It's about 128k > of 4k pages (just shy of the 131072 I'd expect), which is a surprisingly > round number. Also one that's easy to implement in hardware. So it > certainly "smells" the same... > > That's why I agree with others that hw.above4g_allow=0 is worth a shot, for > at least diagnostic purposes. This memory wasn't used before and if it's > used now by the drm drivers, and those aren't PAE safe (meaning they cope > with allocations beyond 4GB), then that's quite useful to know. Or maybe > it's a different driver hating things and stomping on video memory due to > wrap around. > > Warner Thanks for the explanation. Here's an update. TL;DR: xorg is up and running; drm-legacy-kmod seems to be unsafe/unaware of PAE. Build world/kernel, drm-legacy-kmod, minimum needed ports for xorg. Kernel is unmodified GENERIC. Reboot without setting anything in /boot/loader.conf % sysctl -a | grep above % sysctl -a | grep pae vm.pmap.pae_mode: 1 % kldload /boot/modules/i915kms.ko Black screen of death. Did not even get to running xinit. Hard reset to single user mode. # fsck -y # mount -a # vi /boot/loader.conf. (Add hw.above4g_allow=0) # sync # shutdown -r now % sysctl -a | grep above % sysctl -a | grep pae vm.pmap.pae_mode: 1 % cat /boot/loader.conf if_ath_load="YES" if_ath_pci_load="YES" cpuctl_load="YES" hw.above4g_allow=0 % kldload /boot/modules/i915kms.ko Switch to vt3, login as normal user. % startx -- -depth 24 >& ~/tmp/.x.out Xorg is up and running. Not sure why my first attempt at using hw.above4g_allow=0 did not work. Perhaps, mismatch between the xorg bits and kernel/world bits. % sysctl -a | grep mem vm.lowmem_period: 10 vm.kmem_map_free: 1669365760 vm.kmem_map_size: 41910272 vm.kmem_size_scale: 1 vm.kmem_size_max: 1711276032 vm.kmem_size_min: 12582912 vm.kmem_zmax: 65536 vm.kmem_size: 1711276032 hw.physmem: 3715489792 hw.usermem: 3592175616 hw.realmem: 4294963200 % dmesg | grep memory real memory = 4294967296 (4096 MB) avail memory = 3637673984 (3469 MB) agp0: aperture size is 256M, detected 7676k stolen memory The pre-r343567 dmesg has real memory = 4294967296 (4096 MB) avail memory = 3639914496 (3471 MB) I can live with 2 MB loss. Conclusion, drm-legacy-kmod is not PAE safe/aware. Probably want to put something in /usr/src about possible problems with new pmap.h on i386 FreeBSD. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
> On Sat, Feb 23, 2019 at 10:57 AM Steve Kargl < > s...@troutmask.apl.washington.edu> wrote: > > > Supposely, the laptop only has 4 GB of memory. Not sure how > > it finds memory above 4 GB. > > > > Some older chipsets had a 'hole' in memory that they mapped the PCI bus > into and then remapped RAM in that range up above the 4GB boundary. That's > how it can find memory above 4GB when you have only 4GB of RAM. I hit it > with the PC Card stuff I did back in the day since it broke certain > heuristics I had in the code that turned out to be unwise for many reasons > (not just this one). I don't recall all the details, since it's been so > long ago. > > So I think kib@ is right when he highlights > > +0x0001 - 0x00011ffe7fff, 536772608 bytes (131048 pages) > > as the memory, since this is indeed above the 4GB limit. It's about 128k > of 4k pages (just shy of the 131072 I'd expect), which is a surprisingly > round number. Also one that's easy to implement in hardware. So it > certainly "smells" the same... > > That's why I agree with others that hw.above4g_allow=0 is worth a shot, for It sounds like that this sysctl didnt show up for him, he said he set it, but it does not show up in sysctl when he is booted, that seems very odd, unless it didnt get added until a later commit. > at least diagnostic purposes. This memory wasn't used before and if it's > used now by the drm drivers, and those aren't PAE safe (meaning they cope > with allocations beyond 4GB), then that's quite useful to know. Or maybe > it's a different driver hating things and stomping on video memory due to > wrap around. I'll see if I can spend a few moments this afternoon duplicating this, I have 2 thinkpads that are 64 bit, with >4G of ram, that I can install i386 on and test. -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On Sat, Feb 23, 2019 at 10:04:07AM -0800, Rodney W. Grimes wrote: > > On Sat, Feb 23, 2019 at 11:19:31AM +0200, Konstantin Belousov wrote: > > > On Fri, Feb 22, 2019 at 07:26:44PM -0800, Steve Kargl wrote: > > > > On Thu, Feb 21, 2019 at 10:04:10PM -0800, Steve Kargl wrote: > > > > > On Thu, Feb 21, 2019 at 07:39:25PM -0800, Steve Kargl wrote: > > > > > > r343567 merges the PAE vs non-PAE pmap headers for i386 > > > > > > freebsd. After bisection and dealing with the drm-legacy-kmod > > > > > > fallout, I bisected /usr/src to r343567. Building world and > > > > > > a GENERIC kernel and the minimum set of ports to start Xorg > > > > > > on my Dell Latitude D530 laptop, results in a black screen > > > > > > of death and a locked up laptop (no keyboard, mouse, or video). > > > > > > > > > > > > A comparison of /etc/log/Xorg.0.log for r343566 (Xorg loads > > > > > > and functions) and r353467 (Xorg black screen of death) shows > > > > > > that /boot/modules/i915kms.ko loads correctly as the log > > > > > > files are identical. > > > > > > > > > > > > Comparing dmesg for r343566 to r343567 shows the following > > > > > > > > > > > > --- dmesg.3435662019-02-20 08:13:07.727202000 -0800 > > > > > > +++ dmesg.3435672019-02-21 19:02:24.469562000 -0800 > > > > > > @@ -3,11 +3,11 @@ > > > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, > > > > > > 1993, 1994 > > > > > > The Regents of the University of California. All rights > > > > > > reserved. > > > > > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > > > > > -FreeBSD 13.0-CURRENT r343566 GENERIC i386 > > > > > > +FreeBSD 13.0-CURRENT r343567 GENERIC i386 > > > > > > FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based > > > > > > on LLVM 7.0.1) > > > > > > WARNING: WITNESS option enabled, expect reduced performance. > > > > > > VT(vga): resolution 640x480 > > > > > > -CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.05-MHz > > > > > > 686-class CPU) > > > > > > +CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz > > > > > > 686-class CPU) > > > > > >Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf > > > > > > Stepping=13 > > > > > > > > > > > > Features=0xbfebfbff > > > > > > > > > > > > Features2=0xe3bd > > > > > > @@ -16,7 +16,7 @@ > > > > > >VT-x: (disabled in BIOS) HLT,PAUSE > > > > > >TSC: P-state invariant, performance statistics > > > > > > real memory = 4294967296 (4096 MB) > > > > > > -avail memory = 3639914496 (3471 MB) > > > > > > +avail memory = 4154175488 (3961 MB) > > > > > > > > > > > > Somehow the r343567 kernel found an addition 490 MB of memory, > > > > > > which leads me to believe the after loading i915kms.ko there > > > > > > is some serious memory stomping issues. > > > > > > > > > > > > I willing to do whatever is necessary to fix this issue (shorter > > > > > > of mailing the laptop to someone). Is it possible to revert > > > > > > r343567 and move forward? > > > > > > > > > > > > > > > > More info from sysctl. With the "good" r343566, I see > > > > > > > > > > vm.kmem_map_free: 1187033088 > > > > > vm.kmem_map_size: 27234304 > > > > > vm.kmem_size_scale: 3 > > > > > vm.kmem_size_max: 1715470336 > > > > > vm.kmem_size_min: 12582912 > > > > > vm.kmem_zmax: 65536 > > > > > vm.kmem_size: 1214267392 > > > > > hw.physmem: 3714269184 > > > > > hw.usermem: 3650867200 > > > > > hw.realmem: 4294963200 > > > > > > > > > > With the problematic r343567, I see > > > > > > > > > > vm.kmem_map_free: 1683152896 > > > > > vm.kmem_map_size: 28123136 > > > > > vm.kmem_size_scale: 1 > > > > > vm.kmem_size_max: 1711276032 > > > > > vm.kmem_size_min: 12582912 > > > > > vm.kmem_zmax: 65536 > > > > > vm.kmem_size: 1711276032 > > > > > hw.physmem: 4252360704 > > > > > hw.usermem: 4146999296 > > > > > hw.realmem: 4294963200 > > > > > > > > > > Ideas? > > > > > > > > > > > > > Here's the 'diff -uw' between a verbose dmesg boot of r343566 > > > > and dmesg boot of r343567. The memory size looks rather puzzling. > > > > Can the people responsible for the i386 pmap.h merging take a > > > > look? > > > What is puzzling ? > > > > Supposely, the laptop only has 4 GB of memory. Not sure how > > it finds memory above 4 GB. > > It probably has what is called UMA and the graphics > framebuffer is mapped into memory below 4G and the > original memory is mapped above 4G, giving you this > little bit of >4G memory that is trigger PAE now. The PCI window takes between 300M up to 1G, so if 4G of RAM is installed, the same amount is wasted because it is remapped above 4G, regardless of the CPU bitness. > > This may not be desired, is there any performance > advantage to not turning on PAE in this situation? PAE enables nx bit, this was the main reason for the PAE commit. > > > I build 343566 and minimum ports needed for Xorg including > > drm-legacy-kmod. I can load xorg, and in fact, I am typing > > this email now on the laptop
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On Sat, Feb 23, 2019 at 10:57 AM Steve Kargl < s...@troutmask.apl.washington.edu> wrote: > Supposely, the laptop only has 4 GB of memory. Not sure how > it finds memory above 4 GB. > Some older chipsets had a 'hole' in memory that they mapped the PCI bus into and then remapped RAM in that range up above the 4GB boundary. That's how it can find memory above 4GB when you have only 4GB of RAM. I hit it with the PC Card stuff I did back in the day since it broke certain heuristics I had in the code that turned out to be unwise for many reasons (not just this one). I don't recall all the details, since it's been so long ago. So I think kib@ is right when he highlights > +0x0001 - 0x00011ffe7fff, 536772608 bytes (131048 pages) as the memory, since this is indeed above the 4GB limit. It's about 128k of 4k pages (just shy of the 131072 I'd expect), which is a surprisingly round number. Also one that's easy to implement in hardware. So it certainly "smells" the same... That's why I agree with others that hw.above4g_allow=0 is worth a shot, for at least diagnostic purposes. This memory wasn't used before and if it's used now by the drm drivers, and those aren't PAE safe (meaning they cope with allocations beyond 4GB), then that's quite useful to know. Or maybe it's a different driver hating things and stomping on video memory due to wrap around. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On Sat, Feb 23, 2019 at 01:22:28PM +0300, Vladimir Kondratyev wrote: > On 2019-02-22 09:04, Steve Kargl wrote: > > > > Ideas? > > Place hw.above4g_allow=0 into /boot/loader.conf? > Tried that. sysctl -a does not report hw.above4g_allowed, so have no idea if it set. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On Sat, Feb 23, 2019 at 12:44 AM Steve Kargl wrote: > Ideas? > ... > +CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz 686-class > CPU) >Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 https://ark.intel.com/content/www/us/en/ark/products/31728/intel-core-2-duo-processor-t7250-2m-cache-2-00-ghz-800-mhz-fsb.html > Intel® Virtualization Technology (VT-x) ‡ Yes > Intel® 64 ‡ Yes > Merom is the first Intel mobile processor to feature Intel 64 architecture. So, as a workaround, maybe run amd64? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
> On Sat, Feb 23, 2019 at 11:19:31AM +0200, Konstantin Belousov wrote: > > On Fri, Feb 22, 2019 at 07:26:44PM -0800, Steve Kargl wrote: > > > On Thu, Feb 21, 2019 at 10:04:10PM -0800, Steve Kargl wrote: > > > > On Thu, Feb 21, 2019 at 07:39:25PM -0800, Steve Kargl wrote: > > > > > r343567 merges the PAE vs non-PAE pmap headers for i386 > > > > > freebsd. After bisection and dealing with the drm-legacy-kmod > > > > > fallout, I bisected /usr/src to r343567. Building world and > > > > > a GENERIC kernel and the minimum set of ports to start Xorg > > > > > on my Dell Latitude D530 laptop, results in a black screen > > > > > of death and a locked up laptop (no keyboard, mouse, or video). > > > > > > > > > > A comparison of /etc/log/Xorg.0.log for r343566 (Xorg loads > > > > > and functions) and r353467 (Xorg black screen of death) shows > > > > > that /boot/modules/i915kms.ko loads correctly as the log > > > > > files are identical. > > > > > > > > > > Comparing dmesg for r343566 to r343567 shows the following > > > > > > > > > > --- dmesg.343566 2019-02-20 08:13:07.727202000 -0800 > > > > > +++ dmesg.343567 2019-02-21 19:02:24.469562000 -0800 > > > > > @@ -3,11 +3,11 @@ > > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, > > > > > 1994 > > > > > The Regents of the University of California. All rights > > > > > reserved. > > > > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > > > > -FreeBSD 13.0-CURRENT r343566 GENERIC i386 > > > > > +FreeBSD 13.0-CURRENT r343567 GENERIC i386 > > > > > FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based > > > > > on LLVM 7.0.1) > > > > > WARNING: WITNESS option enabled, expect reduced performance. > > > > > VT(vga): resolution 640x480 > > > > > -CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.05-MHz > > > > > 686-class CPU) > > > > > +CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz > > > > > 686-class CPU) > > > > >Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 > > > > > > > > > > Features=0xbfebfbff > > > > > > > > > > Features2=0xe3bd > > > > > @@ -16,7 +16,7 @@ > > > > >VT-x: (disabled in BIOS) HLT,PAUSE > > > > >TSC: P-state invariant, performance statistics > > > > > real memory = 4294967296 (4096 MB) > > > > > -avail memory = 3639914496 (3471 MB) > > > > > +avail memory = 4154175488 (3961 MB) > > > > > > > > > > Somehow the r343567 kernel found an addition 490 MB of memory, > > > > > which leads me to believe the after loading i915kms.ko there > > > > > is some serious memory stomping issues. > > > > > > > > > > I willing to do whatever is necessary to fix this issue (shorter > > > > > of mailing the laptop to someone). Is it possible to revert > > > > > r343567 and move forward? > > > > > > > > > > > > > More info from sysctl. With the "good" r343566, I see > > > > > > > > vm.kmem_map_free: 1187033088 > > > > vm.kmem_map_size: 27234304 > > > > vm.kmem_size_scale: 3 > > > > vm.kmem_size_max: 1715470336 > > > > vm.kmem_size_min: 12582912 > > > > vm.kmem_zmax: 65536 > > > > vm.kmem_size: 1214267392 > > > > hw.physmem: 3714269184 > > > > hw.usermem: 3650867200 > > > > hw.realmem: 4294963200 > > > > > > > > With the problematic r343567, I see > > > > > > > > vm.kmem_map_free: 1683152896 > > > > vm.kmem_map_size: 28123136 > > > > vm.kmem_size_scale: 1 > > > > vm.kmem_size_max: 1711276032 > > > > vm.kmem_size_min: 12582912 > > > > vm.kmem_zmax: 65536 > > > > vm.kmem_size: 1711276032 > > > > hw.physmem: 4252360704 > > > > hw.usermem: 4146999296 > > > > hw.realmem: 4294963200 > > > > > > > > Ideas? > > > > > > > > > > Here's the 'diff -uw' between a verbose dmesg boot of r343566 > > > and dmesg boot of r343567. The memory size looks rather puzzling. > > > Can the people responsible for the i386 pmap.h merging take a > > > look? > > What is puzzling ? > > Supposely, the laptop only has 4 GB of memory. Not sure how > it finds memory above 4 GB. It probably has what is called UMA and the graphics framebuffer is mapped into memory below 4G and the original memory is mapped above 4G, giving you this little bit of >4G memory that is trigger PAE now. This may not be desired, is there any performance advantage to not turning on PAE in this situation? > I build 343566 and minimum ports needed for Xorg including > drm-legacy-kmod. I can load xorg, and in fact, I am typing > this email now on the laptop with vi in xterm. > > I build 343567 and minimum ports needed for Xorg including > drm-legacy-kmod. I try to start Xorg. Black screen of death. > No mouse. No keyboard. Just a hard reset. That would be a regression caused by PAE coming into play. > I build 343567 and minimum ports needed for Xorg including > drm-legacy-kmod. I load i915kms.ko, do not start Xorg. There > are surprising strikes/blotches of color on screen. Building any > port with the system's cc results in occasion segfaults. > > >
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On Sat, Feb 23, 2019 at 08:32:23AM -0800, Conrad Meyer wrote: > On Sat, Feb 23, 2019 at 12:44 AM Steve Kargl > wrote: > > Ideas? > > ... > > +CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz > > 686-class CPU) > >Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 > > https://ark.intel.com/content/www/us/en/ark/products/31728/intel-core-2-duo-processor-t7250-2m-cache-2-00-ghz-800-mhz-fsb.html > > > Intel® Virtualization Technology (VT-x) ‡ Yes > > Intel® 64 ‡ Yes > > > Merom is the first Intel mobile processor to feature Intel 64 architecture. > > So, as a workaround, maybe run amd64? This is the only i386 FreeBSD system that I have. This is the system where all the libm changes I've made have been tested. i386 floating point is different than amd64 floating point. See npx.c and the history of any of the long double functions that I've worked on. If this laptop does not run i386, there will be no testing of libm changes on the architecture. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On Sat, Feb 23, 2019 at 11:19:31AM +0200, Konstantin Belousov wrote: > On Fri, Feb 22, 2019 at 07:26:44PM -0800, Steve Kargl wrote: > > On Thu, Feb 21, 2019 at 10:04:10PM -0800, Steve Kargl wrote: > > > On Thu, Feb 21, 2019 at 07:39:25PM -0800, Steve Kargl wrote: > > > > r343567 merges the PAE vs non-PAE pmap headers for i386 > > > > freebsd. After bisection and dealing with the drm-legacy-kmod > > > > fallout, I bisected /usr/src to r343567. Building world and > > > > a GENERIC kernel and the minimum set of ports to start Xorg > > > > on my Dell Latitude D530 laptop, results in a black screen > > > > of death and a locked up laptop (no keyboard, mouse, or video). > > > > > > > > A comparison of /etc/log/Xorg.0.log for r343566 (Xorg loads > > > > and functions) and r353467 (Xorg black screen of death) shows > > > > that /boot/modules/i915kms.ko loads correctly as the log > > > > files are identical. > > > > > > > > Comparing dmesg for r343566 to r343567 shows the following > > > > > > > > --- dmesg.3435662019-02-20 08:13:07.727202000 -0800 > > > > +++ dmesg.3435672019-02-21 19:02:24.469562000 -0800 > > > > @@ -3,11 +3,11 @@ > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, > > > > 1994 > > > > The Regents of the University of California. All rights > > > > reserved. > > > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > > > -FreeBSD 13.0-CURRENT r343566 GENERIC i386 > > > > +FreeBSD 13.0-CURRENT r343567 GENERIC i386 > > > > FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on > > > > LLVM 7.0.1) > > > > WARNING: WITNESS option enabled, expect reduced performance. > > > > VT(vga): resolution 640x480 > > > > -CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.05-MHz > > > > 686-class CPU) > > > > +CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz > > > > 686-class CPU) > > > >Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 > > > > > > > > Features=0xbfebfbff > > > > > > > > Features2=0xe3bd > > > > @@ -16,7 +16,7 @@ > > > >VT-x: (disabled in BIOS) HLT,PAUSE > > > >TSC: P-state invariant, performance statistics > > > > real memory = 4294967296 (4096 MB) > > > > -avail memory = 3639914496 (3471 MB) > > > > +avail memory = 4154175488 (3961 MB) > > > > > > > > Somehow the r343567 kernel found an addition 490 MB of memory, > > > > which leads me to believe the after loading i915kms.ko there > > > > is some serious memory stomping issues. > > > > > > > > I willing to do whatever is necessary to fix this issue (shorter > > > > of mailing the laptop to someone). Is it possible to revert > > > > r343567 and move forward? > > > > > > > > > > More info from sysctl. With the "good" r343566, I see > > > > > > vm.kmem_map_free: 1187033088 > > > vm.kmem_map_size: 27234304 > > > vm.kmem_size_scale: 3 > > > vm.kmem_size_max: 1715470336 > > > vm.kmem_size_min: 12582912 > > > vm.kmem_zmax: 65536 > > > vm.kmem_size: 1214267392 > > > hw.physmem: 3714269184 > > > hw.usermem: 3650867200 > > > hw.realmem: 4294963200 > > > > > > With the problematic r343567, I see > > > > > > vm.kmem_map_free: 1683152896 > > > vm.kmem_map_size: 28123136 > > > vm.kmem_size_scale: 1 > > > vm.kmem_size_max: 1711276032 > > > vm.kmem_size_min: 12582912 > > > vm.kmem_zmax: 65536 > > > vm.kmem_size: 1711276032 > > > hw.physmem: 4252360704 > > > hw.usermem: 4146999296 > > > hw.realmem: 4294963200 > > > > > > Ideas? > > > > > > > Here's the 'diff -uw' between a verbose dmesg boot of r343566 > > and dmesg boot of r343567. The memory size looks rather puzzling. > > Can the people responsible for the i386 pmap.h merging take a > > look? > What is puzzling ? Supposely, the laptop only has 4 GB of memory. Not sure how it finds memory above 4 GB. I build 343566 and minimum ports needed for Xorg including drm-legacy-kmod. I can load xorg, and in fact, I am typing this email now on the laptop with vi in xterm. I build 343567 and minimum ports needed for Xorg including drm-legacy-kmod. I try to start Xorg. Black screen of death. No mouse. No keyboard. Just a hard reset. I build 343567 and minimum ports needed for Xorg including drm-legacy-kmod. I load i915kms.ko, do not start Xorg. There are surprising strikes/blotches of color on screen. Building any port with the system's cc results in occasion segfaults. > When kernel boots in PAE mode, it can (and will) get a use for physical > memory mapped above 4G. I highlighted the SMAP entry which represents > such memory, below. > > kmem_scale was changed in the PAE commit, see the commit message for > explanation. > I read it multiple times. It does not explain how to get the old pre-343567 behavior where the laptop is usable. It mentions two new sysctl entities. One is irrelevant as I don't have 24+ GB of memory. The other has this in the commit message: There are two tunables added: hw.above4g_allow and ..., the
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On 2019-02-22 09:04, Steve Kargl wrote: Ideas? Place hw.above4g_allow=0 into /boot/loader.conf? -- WBR Vladimir Kondratyev ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On Fri, Feb 22, 2019 at 07:26:44PM -0800, Steve Kargl wrote: > On Thu, Feb 21, 2019 at 10:04:10PM -0800, Steve Kargl wrote: > > On Thu, Feb 21, 2019 at 07:39:25PM -0800, Steve Kargl wrote: > > > r343567 merges the PAE vs non-PAE pmap headers for i386 > > > freebsd. After bisection and dealing with the drm-legacy-kmod > > > fallout, I bisected /usr/src to r343567. Building world and > > > a GENERIC kernel and the minimum set of ports to start Xorg > > > on my Dell Latitude D530 laptop, results in a black screen > > > of death and a locked up laptop (no keyboard, mouse, or video). > > > > > > A comparison of /etc/log/Xorg.0.log for r343566 (Xorg loads > > > and functions) and r353467 (Xorg black screen of death) shows > > > that /boot/modules/i915kms.ko loads correctly as the log > > > files are identical. > > > > > > Comparing dmesg for r343566 to r343567 shows the following > > > > > > --- dmesg.343566 2019-02-20 08:13:07.727202000 -0800 > > > +++ dmesg.343567 2019-02-21 19:02:24.469562000 -0800 > > > @@ -3,11 +3,11 @@ > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > > The Regents of the University of California. All rights reserved. > > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > > -FreeBSD 13.0-CURRENT r343566 GENERIC i386 > > > +FreeBSD 13.0-CURRENT r343567 GENERIC i386 > > > FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on > > > LLVM 7.0.1) > > > WARNING: WITNESS option enabled, expect reduced performance. > > > VT(vga): resolution 640x480 > > > -CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.05-MHz > > > 686-class CPU) > > > +CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz > > > 686-class CPU) > > >Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 > > > > > > Features=0xbfebfbff > > > > > > Features2=0xe3bd > > > @@ -16,7 +16,7 @@ > > >VT-x: (disabled in BIOS) HLT,PAUSE > > >TSC: P-state invariant, performance statistics > > > real memory = 4294967296 (4096 MB) > > > -avail memory = 3639914496 (3471 MB) > > > +avail memory = 4154175488 (3961 MB) > > > > > > Somehow the r343567 kernel found an addition 490 MB of memory, > > > which leads me to believe the after loading i915kms.ko there > > > is some serious memory stomping issues. > > > > > > I willing to do whatever is necessary to fix this issue (shorter > > > of mailing the laptop to someone). Is it possible to revert > > > r343567 and move forward? > > > > > > > More info from sysctl. With the "good" r343566, I see > > > > vm.kmem_map_free: 1187033088 > > vm.kmem_map_size: 27234304 > > vm.kmem_size_scale: 3 > > vm.kmem_size_max: 1715470336 > > vm.kmem_size_min: 12582912 > > vm.kmem_zmax: 65536 > > vm.kmem_size: 1214267392 > > hw.physmem: 3714269184 > > hw.usermem: 3650867200 > > hw.realmem: 4294963200 > > > > With the problematic r343567, I see > > > > vm.kmem_map_free: 1683152896 > > vm.kmem_map_size: 28123136 > > vm.kmem_size_scale: 1 > > vm.kmem_size_max: 1711276032 > > vm.kmem_size_min: 12582912 > > vm.kmem_zmax: 65536 > > vm.kmem_size: 1711276032 > > hw.physmem: 4252360704 > > hw.usermem: 4146999296 > > hw.realmem: 4294963200 > > > > Ideas? > > > > Here's the 'diff -uw' between a verbose dmesg boot of r343566 > and dmesg boot of r343567. The memory size looks rather puzzling. > Can the people responsible for the i386 pmap.h merging take a > look? What is puzzling ? When kernel boots in PAE mode, it can (and will) get a use for physical memory mapped above 4G. I highlighted the SMAP entry which represents such memory, below. kmem_scale was changed in the PAE commit, see the commit message for explanation. > > --- dmesg.343566.verbose 2019-02-22 19:08:33.458559000 -0800 > +++ dmesg.343567.verbose 2019-02-22 08:55:21.62331 -0800 > @@ -8,25 +8,25 @@ > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > -FreeBSD 13.0-CURRENT r343566 GENERIC i386 > +FreeBSD 13.0-CURRENT r343567 GENERIC i386 > FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM > 7.0.1) > WARNING: WITNESS option enabled, expect reduced performance. > VT(vga): resolution 640x480 > -Preloaded elf kernel "/boot/kernel/kernel" at 0x2501000. > -Preloaded boot_entropy_cache "/boot/entropy" at 0x2509b20. > -Preloaded elf module "/boot/kernel/cpuctl.ko" at 0x2509b6c. > -Preloaded elf module "/boot/kernel/if_ath.ko" at 0x2509f68. > -Preloaded elf module "/boot/kernel/ath_dfs.ko" at 0x250a314. > -Preloaded elf module "/boot/kernel/ath_rate.ko" at 0x250a6c0. > -Preloaded elf module "/boot/kernel/ath_hal_ar9300.ko" at 0x250aa70. > -Preloaded elf module "/boot/kernel/ath_hal_ar5416.ko" at 0x250ae9c. > -Preloaded elf module "/boot/kernel/ath_hal_ar5212.ko" at 0x250b2c8. > -Preloaded elf module "/boot/kernel/ath_hal_a
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On Thu, Feb 21, 2019 at 10:04:10PM -0800, Steve Kargl wrote: > On Thu, Feb 21, 2019 at 07:39:25PM -0800, Steve Kargl wrote: > > r343567 merges the PAE vs non-PAE pmap headers for i386 > > freebsd. After bisection and dealing with the drm-legacy-kmod > > fallout, I bisected /usr/src to r343567. Building world and > > a GENERIC kernel and the minimum set of ports to start Xorg > > on my Dell Latitude D530 laptop, results in a black screen > > of death and a locked up laptop (no keyboard, mouse, or video). > > > > A comparison of /etc/log/Xorg.0.log for r343566 (Xorg loads > > and functions) and r353467 (Xorg black screen of death) shows > > that /boot/modules/i915kms.ko loads correctly as the log > > files are identical. > > > > Comparing dmesg for r343566 to r343567 shows the following > > > > --- dmesg.3435662019-02-20 08:13:07.727202000 -0800 > > +++ dmesg.3435672019-02-21 19:02:24.469562000 -0800 > > @@ -3,11 +3,11 @@ > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > -FreeBSD 13.0-CURRENT r343566 GENERIC i386 > > +FreeBSD 13.0-CURRENT r343567 GENERIC i386 > > FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM > > 7.0.1) > > WARNING: WITNESS option enabled, expect reduced performance. > > VT(vga): resolution 640x480 > > -CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.05-MHz > > 686-class CPU) > > +CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz > > 686-class CPU) > >Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 > > > > Features=0xbfebfbff > >Features2=0xe3bd > > @@ -16,7 +16,7 @@ > >VT-x: (disabled in BIOS) HLT,PAUSE > >TSC: P-state invariant, performance statistics > > real memory = 4294967296 (4096 MB) > > -avail memory = 3639914496 (3471 MB) > > +avail memory = 4154175488 (3961 MB) > > > > Somehow the r343567 kernel found an addition 490 MB of memory, > > which leads me to believe the after loading i915kms.ko there > > is some serious memory stomping issues. > > > > I willing to do whatever is necessary to fix this issue (shorter > > of mailing the laptop to someone). Is it possible to revert > > r343567 and move forward? > > > > More info from sysctl. With the "good" r343566, I see > > vm.kmem_map_free: 1187033088 > vm.kmem_map_size: 27234304 > vm.kmem_size_scale: 3 > vm.kmem_size_max: 1715470336 > vm.kmem_size_min: 12582912 > vm.kmem_zmax: 65536 > vm.kmem_size: 1214267392 > hw.physmem: 3714269184 > hw.usermem: 3650867200 > hw.realmem: 4294963200 > > With the problematic r343567, I see > > vm.kmem_map_free: 1683152896 > vm.kmem_map_size: 28123136 > vm.kmem_size_scale: 1 > vm.kmem_size_max: 1711276032 > vm.kmem_size_min: 12582912 > vm.kmem_zmax: 65536 > vm.kmem_size: 1711276032 > hw.physmem: 4252360704 > hw.usermem: 4146999296 > hw.realmem: 4294963200 > > Ideas? > Here's the 'diff -uw' between a verbose dmesg boot of r343566 and dmesg boot of r343567. The memory size looks rather puzzling. Can the people responsible for the i386 pmap.h merging take a look? --- dmesg.343566.verbose2019-02-22 19:08:33.458559000 -0800 +++ dmesg.343567.verbose2019-02-22 08:55:21.62331 -0800 @@ -8,25 +8,25 @@ Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. -FreeBSD 13.0-CURRENT r343566 GENERIC i386 +FreeBSD 13.0-CURRENT r343567 GENERIC i386 FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM 7.0.1) WARNING: WITNESS option enabled, expect reduced performance. VT(vga): resolution 640x480 -Preloaded elf kernel "/boot/kernel/kernel" at 0x2501000. -Preloaded boot_entropy_cache "/boot/entropy" at 0x2509b20. -Preloaded elf module "/boot/kernel/cpuctl.ko" at 0x2509b6c. -Preloaded elf module "/boot/kernel/if_ath.ko" at 0x2509f68. -Preloaded elf module "/boot/kernel/ath_dfs.ko" at 0x250a314. -Preloaded elf module "/boot/kernel/ath_rate.ko" at 0x250a6c0. -Preloaded elf module "/boot/kernel/ath_hal_ar9300.ko" at 0x250aa70. -Preloaded elf module "/boot/kernel/ath_hal_ar5416.ko" at 0x250ae9c. -Preloaded elf module "/boot/kernel/ath_hal_ar5212.ko" at 0x250b2c8. -Preloaded elf module "/boot/kernel/ath_hal_ar5211.ko" at 0x250b6f4. -Preloaded elf module "/boot/kernel/ath_hal_ar5210.ko" at 0x250baf8. +Preloaded elf kernel "/boot/kernel/kernel" at 0x2528000. +Preloaded elf module "/boot/kernel/cpuctl.ko" at 0x2530b20. +Preloaded boot_entropy_cache "/boot/entropy" at 0x2530f1c. +Preloaded elf module "/boot/kernel/if_ath.ko" at 0x2530f68. +Preloaded elf module "/boot/kernel/ath_dfs.ko" at 0x2531314. +Preloaded elf module "/boot/kernel/ath_rate.ko" at 0x25316c0. +Preloaded elf module "/boot/kernel/ath_hal_ar9300.ko" at 0x2531a70. +Preloaded e
Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On Thu, Feb 21, 2019 at 07:39:25PM -0800, Steve Kargl wrote: > r343567 merges the PAE vs non-PAE pmap headers for i386 > freebsd. After bisection and dealing with the drm-legacy-kmod > fallout, I bisected /usr/src to r343567. Building world and > a GENERIC kernel and the minimum set of ports to start Xorg > on my Dell Latitude D530 laptop, results in a black screen > of death and a locked up laptop (no keyboard, mouse, or video). > > A comparison of /etc/log/Xorg.0.log for r343566 (Xorg loads > and functions) and r353467 (Xorg black screen of death) shows > that /boot/modules/i915kms.ko loads correctly as the log > files are identical. > > Comparing dmesg for r343566 to r343567 shows the following > > --- dmesg.343566 2019-02-20 08:13:07.727202000 -0800 > +++ dmesg.343567 2019-02-21 19:02:24.469562000 -0800 > @@ -3,11 +3,11 @@ > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > -FreeBSD 13.0-CURRENT r343566 GENERIC i386 > +FreeBSD 13.0-CURRENT r343567 GENERIC i386 > FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM > 7.0.1) > WARNING: WITNESS option enabled, expect reduced performance. > VT(vga): resolution 640x480 > -CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.05-MHz 686-class > CPU) > +CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz 686-class > CPU) >Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 > > Features=0xbfebfbff >Features2=0xe3bd > @@ -16,7 +16,7 @@ >VT-x: (disabled in BIOS) HLT,PAUSE >TSC: P-state invariant, performance statistics > real memory = 4294967296 (4096 MB) > -avail memory = 3639914496 (3471 MB) > +avail memory = 4154175488 (3961 MB) > > Somehow the r343567 kernel found an addition 490 MB of memory, > which leads me to believe the after loading i915kms.ko there > is some serious memory stomping issues. > > I willing to do whatever is necessary to fix this issue (shorter > of mailing the laptop to someone). Is it possible to revert > r343567 and move forward? > More info from sysctl. With the "good" r343566, I see vm.kmem_map_free: 1187033088 vm.kmem_map_size: 27234304 vm.kmem_size_scale: 3 vm.kmem_size_max: 1715470336 vm.kmem_size_min: 12582912 vm.kmem_zmax: 65536 vm.kmem_size: 1214267392 hw.physmem: 3714269184 hw.usermem: 3650867200 hw.realmem: 4294963200 With the problematic r343567, I see vm.kmem_map_free: 1683152896 vm.kmem_map_size: 28123136 vm.kmem_size_scale: 1 vm.kmem_size_max: 1711276032 vm.kmem_size_min: 12582912 vm.kmem_zmax: 65536 vm.kmem_size: 1711276032 hw.physmem: 4252360704 hw.usermem: 4146999296 hw.realmem: 4294963200 Ideas? -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r343567 aka PAE vs non-PAE merge breaks i386 freebsd
r343567 merges the PAE vs non-PAE pmap headers for i386 freebsd. After bisection and dealing with the drm-legacy-kmod fallout, I bisected /usr/src to r343567. Building world and a GENERIC kernel and the minimum set of ports to start Xorg on my Dell Latitude D530 laptop, results in a black screen of death and a locked up laptop (no keyboard, mouse, or video). A comparison of /etc/log/Xorg.0.log for r343566 (Xorg loads and functions) and r353467 (Xorg black screen of death) shows that /boot/modules/i915kms.ko loads correctly as the log files are identical. Comparing dmesg for r343566 to r343567 shows the following --- dmesg.3435662019-02-20 08:13:07.727202000 -0800 +++ dmesg.3435672019-02-21 19:02:24.469562000 -0800 @@ -3,11 +3,11 @@ Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. -FreeBSD 13.0-CURRENT r343566 GENERIC i386 +FreeBSD 13.0-CURRENT r343567 GENERIC i386 FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM 7.0.1) WARNING: WITNESS option enabled, expect reduced performance. VT(vga): resolution 640x480 -CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.05-MHz 686-class CPU) +CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz 686-class CPU) Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 Features=0xbfebfbff Features2=0xe3bd @@ -16,7 +16,7 @@ VT-x: (disabled in BIOS) HLT,PAUSE TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) -avail memory = 3639914496 (3471 MB) +avail memory = 4154175488 (3961 MB) Somehow the r343567 kernel found an addition 490 MB of memory, which leads me to believe the after loading i915kms.ko there is some serious memory stomping issues. I willing to do whatever is necessary to fix this issue (shorter of mailing the laptop to someone). Is it possible to revert r343567 and move forward? -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
