Bug#652469: Fwd: Re: Bug#652469: Bug#652448: panic when booting on a machine with >= 4 GiB of RAM
El 17 de desembre de 2011 21:23, Edward Tomasz Napierała ha escrit: > Wiadomość napisana przez Arno Töll w dniu 17 gru 2011, o godz. 16:12: >>> Maybe we should discuss this with FreeBSD? We could even propose them >>> to make SMP the default there. > > SMP has been enabled in the the default FreeBSD kernel (GENERIC) > for quite some time now. Oh, sorry, I've been looking at the patched file in Debian (we remove it from GENERIC and add it back via debian/arch/). Thanks for correcting me. In that case, how about: - Add SMP for all flavours - Replace -smp flavour with -pae flavour ? -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caofdtxokf_yszzjqegrlywchuwqcj6vus76hshke-cqre0r...@mail.gmail.com
Bug#652469: Fwd: Re: Bug#652469: Bug#652448: panic when booting on a machine with >= 4 GiB of RAM
Wiadomość napisana przez Arno Töll w dniu 17 gru 2011, o godz. 16:12: >> Maybe we should discuss this with FreeBSD? We could even propose them >> to make SMP the default there. SMP has been enabled in the the default FreeBSD kernel (GENERIC) for quite some time now. -- If you cut off my head, what would I say? Me and my head, or me and my body? -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/84d9a0cf-6981-4244-a881-566cb2a11...@freebsd.org
Bug#652469: Fwd: Re: Bug#652469: Bug#652448: panic when booting on a machine with >= 4 GiB of RAM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Forward to 652...@bugs.debian.org I forgot, sorry. - Original Message On 17.12.2011 15:49, Robert Millan wrote: > I'm not sure how relevant is > this factor but it is unexistant on GNU/kFreeBSD, so I think this > should be accounted for when taking Linux as reference. More or less unexisting. The very same candidates that would cause one to remain on a IA32 user land because of non-free cruft on Linux mostly also holds FreeBSD as it is typically the very same software people want to run through the Linux emulation layer. Think of Flash and Google Earth for example. That said I have no use for kfreebsd on a desktop and I hence didn't try any of those programs under kfreebsd so far. > Another likely difference is that kFreeBSD in PAE mode has major > drawbacks (in particular we'd have to disable a bunch of drivers, see > sys/i386/conf/PAE and URL I pasted before). All in all, I have the > impression that using PAE would be unacceptable for the majority of > i686 users. That on the other hand is a good rationale not to use PAE. However, if you read the discussion I noted there is no significant performance improvement [on Linux] to use i686 over i486. Thus, users of 686 capable CPUs may happily use the 486 branch, whereas people who need PAE need 686 anyway. > Good question. TBH I really dislike adding new flavours for PAE > unless SMP is merged. Then we'd only have to replace 686-smp with > 686-pae instead of adding two new flavours. We're not freezing tomorrow, maybe consider waiting for upstream regarding SMP support upstream. > I don't know if SMP option is really usable on uniprocessor hardware. > FWIW, I've tested -smp flavours for 8.3 and 9.0 on an uniprocessor VM > and both seem to work fine. I would hope it is usable. If it weren't that would certainly be a bug in the SMP code. However, there might be design decisions that make SMP slower on uniprocessor hardware (or not - I don't know as said). > Maybe we should discuss this with FreeBSD? We could even propose them > to make SMP the default there. That makes sense, yes. In particular I guess we shouldn't be inventing use cases which aren't supported in such a configuration upstream either. > Given that a PAE kernel has important drawbacks (like disabling a lot > of drivers), I'd rather leave it to the user to explicitly install > those kernels after a normal kFreeBSD is running. I wrote that under the impression that such a kernel would crash on systems with more than 4G RAM. That would leave people without possibility to install kfreebsd. If that's sorted out, i.e. the bug has been fixed I am for a non PAE kernel too. I do not think there would be any benefit to use >= 4G RAM in the context of D-I. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJO7LFbAAoJEMcrUe6dgPNtMjQP/ArffA1pH++cbXkYrYKtDuWr gSE/lPpPE8039iEfMIwlma3GE47YxYSf41L57dSfThnZ2nBtTMbt7QDuG+g1dEca s9a5tuIf0QmruwNeiOkhFmxnowPbwmfrORGLS69caJYjc85pjfVQJD56NnB50pcO j8fkr4DyqvG8wqzzSmkkOutaSHkwUm3UbZaemchA2OYlaP20NbhVzkGj9Ze36Nnx 2mYSj8F2XvwzlYwhUqT9puJlSfWCgeWYXQmoGw1+yo8rudkEN7aApUsrADUc4wi6 jP5TxykGtVoZm0Nd0q/+gPhBoddevQZs0afaXGUpltdGxXdw0SjdNWuQfLbqdxtF q6CwTiSEevIirf7+Tqaqo60GVScWr6fwGMw5SnU98FC9lElDUJokN2/DWzeTfBW0 duwyC7lGqOlKeIzCbRYj/KOJDOEh7uT5kBXcD/Em18hBzC86ypjQZeYDOTrhJ+Jp FNkjoQ+iGC9l1hC/sUWkEsSgX0MDFMGv8RAJ4kp42MAZZb4zl+6keDsU4L3/pgBA Zc1Vlm9YmxkjAwqDD4NZWsUGsL8T2AgiZXO9oYU3Whgk2jfhStqq/d5hBmwOzbvy hgx4dtGpdgsmfaaMts+uw66D0cHh6cag0w6WE0QgnXUhayW/yAVSZJpU7dS0NVIS 4gdTDnXPmAmF9TH+qWDr =E/Ed -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eecb15b.7070...@toell.net
Re: Bug#652469: Bug#652448: panic when booting on a machine with >= 4 GiB of RAM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17.12.2011 15:49, Robert Millan wrote: > I'm not sure how relevant is > this factor but it is unexistant on GNU/kFreeBSD, so I think this > should be accounted for when taking Linux as reference. More or less unexisting. The very same candidates that would cause one to remain on a IA32 user land because of non-free cruft on Linux mostly also holds FreeBSD as it is typically the very same software people want to run through the Linux emulation layer. Think of Flash and Google Earth for example. That said I have no use for kfreebsd on a desktop and I hence didn't try any of those programs under kfreebsd so far. > Another likely difference is that kFreeBSD in PAE mode has major > drawbacks (in particular we'd have to disable a bunch of drivers, see > sys/i386/conf/PAE and URL I pasted before). All in all, I have the > impression that using PAE would be unacceptable for the majority of > i686 users. That on the other hand is a good rationale not to use PAE. However, if you read the discussion I noted there is no significant performance improvement [on Linux] to use i686 over i486. Thus, users of 686 capable CPUs may happily use the 486 branch, whereas people who need PAE need 686 anyway. > Good question. TBH I really dislike adding new flavours for PAE > unless SMP is merged. Then we'd only have to replace 686-smp with > 686-pae instead of adding two new flavours. We're not freezing tomorrow, maybe consider waiting for upstream regarding SMP support upstream. > I don't know if SMP option is really usable on uniprocessor hardware. > FWIW, I've tested -smp flavours for 8.3 and 9.0 on an uniprocessor VM > and both seem to work fine. I would hope it is usable. If it weren't that would certainly be a bug in the SMP code. However, there might be design decisions that make SMP slower on uniprocessor hardware (or not - I don't know as said). > Maybe we should discuss this with FreeBSD? We could even propose them > to make SMP the default there. That makes sense, yes. In particular I guess we shouldn't be inventing use cases which aren't supported in such a configuration upstream either. > Given that a PAE kernel has important drawbacks (like disabling a lot > of drivers), I'd rather leave it to the user to explicitly install > those kernels after a normal kFreeBSD is running. I wrote that under the impression that such a kernel would crash on systems with more than 4G RAM. That would leave people without possibility to install kfreebsd. If that's sorted out, i.e. the bug has been fixed I am for a non PAE kernel too. I do not think there would be any benefit to use >= 4G RAM in the context of D-I. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJO7LCsAAoJEMcrUe6dgPNtTSwQAKHBVtEWDs+KbjmkHjMRtRSQ YOW2wtqU2sStexJv39oKYs7TlW9A7os6Qg30fKWBQGa17j6xHFSmn8/TqK1dqKfQ EW2xSe7my7Oa9oleuLZoCkIzodvloKXhtDZEvDGx/br/SM3busw2wSg0Md1MDS0r FthJlc76BhZujMscSLGISeSluRX6qJlBkDKZWY9DeMQbg91f6CLPwVQoPVraDCOd lxRyDCh/RzVxR7Z6yUybEImFJqQw3kPBYKyMV6SxLdLa8C1xMc7B9nRtA2vfJXew 5A7FvPzcQgRaqhg6k0LJ/cSj7eGsCVMddGhWZ1+DS691DEkVgvm7nFWRGx2t4c1P S06X2E7/oP0XBp+h02yw7vLGOxoBweULyLmMlEbs39f4FoMMlUYUzECiHn+7rfXO po0HgT2B2zpzSs5bIIWmVUjjBnmESvWD34H1NTyJDXYAL1X0YhaGW0/6ox5J4SP5 VAMrXOARcSHjLw34he1I6Dj4/kwOCJmEBm/BdWMfNL2VASGJCJ/Cj3m7Mvqb+V3L 1KLEXfHIMPYLZu9NPkm4rrtm9JKgqCX9BA33umqXR8tbemRXvygw/mv45txk2mx1 o4brqOUfs2v0TYziVT7g0tO6ErHQwyA7BiJEyvoxbstpfZfZPEQkXfZ+BKd9KqzJ F2F2491RocLNI4PNuyxh =2Cdd -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eecb0ac.1060...@toell.net
Bug#652469: Bug#652448: panic when booting on a machine with >= 4 GiB of RAM
El 17 de desembre de 2011 13:51, Arno Töll ha escrit: > On 17.12.2011 12:09, Robert Millan wrote: >> - Add additional flavours (which ones? 686, 686-smp ... ? and then >> which ones to provide with D-I?) > > That's what we're doing on Linux and that seems the best compromise. I think on GNU/Linux many people want to use IA32 version even with CPUs that support AMD mode, because they want IA32 userland for binary compatibility with non-free software. I'm not sure how relevant is this factor but it is unexistant on GNU/kFreeBSD, so I think this should be accounted for when taking Linux as reference. Another likely difference is that kFreeBSD in PAE mode has major drawbacks (in particular we'd have to disable a bunch of drivers, see sys/i386/conf/PAE and URL I pasted before). All in all, I have the impression that using PAE would be unacceptable for the majority of i686 users. > On Linux there are many different kernel flavors where it is being worked > on to reduce their amount. I propose -486 for older PCs and 686-pae for > newer PCs. See [1] on more discussion about the minimal required processor. > > I am not sure if FreeBSD has drawbacks to use a SMP flavored kernel on a > traditional legacy system with one CPU only. If yes there perhaps should > be a -smp version for each too. Good question. TBH I really dislike adding new flavours for PAE unless SMP is merged. Then we'd only have to replace 686-smp with 686-pae instead of adding two new flavours. I don't know if SMP option is really usable on uniprocessor hardware. FWIW, I've tested -smp flavours for 8.3 and 9.0 on an uniprocessor VM and both seem to work fine. Maybe we should discuss this with FreeBSD? We could even propose them to make SMP the default there. > Regarding D-I I guess there is no easy way to tell in > advance whether the system needs a PAE kernel or not, Given that a PAE kernel has important drawbacks (like disabling a lot of drivers), I'd rather leave it to the user to explicitly install those kernels after a normal kFreeBSD is running. -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caofdtxnatjqwkpwafzzmue5c_vyropdofdp1eyzwywca6mf...@mail.gmail.com
