Re: LFS-Bootscripts-3.2.1 setclock
On Thu, 3 Nov 2005 01:28:11 -0700 Archaic [EMAIL PROTECTED] wrote: On Thu, Nov 03, 2005 at 05:58:51AM -0100, Duncan Webb wrote: Now that we're no longer in summer time in the Makefile for LFS-Bootscripts-3.2.1 there are no rules to install setclock during a reboot or shutdown. So the hardware clock is not being synchronised with the system clock. It is not safe to assume that the system clock is more accurate than the hwclock unless you are syncing to a time server which is why BLFS adds the needed symlinks *after* NTP is installed and configured. Which probably means that a note to that effect should be in LFS page 7.5 , since not everyone will use BLFS, or even if they do, use ntp (I use chrony, for instance). I know that the referred hint mentions it (just, in a note), but IMO that isn't sufficient. R. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
coreutils uname patch revisited
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I'm installing a LFS ona VIA Epia platform (next step: kernel ;-)),
that has neither an Intel nor AMD processor (VIA C3 Nehemiah aka c3-2).
And after applying the coreutils-5.2.1-uname-2.patch, uname -p returned
i686, which is better than unknown, but I still didn't found good
enough.
So I used the patched version of coreutils and added detection for VIA
(CentaurHauls) C3 and C3-2 processors. And on the process, I also added
the detection for pentium-m (centrino) processors, that was also missing.
I've tested it on my VIA and on a centrino notebook, and seems to work
OK. I haven't changed anything else, just added values to previously
undefined models, so in theory I shouldn't have broken anything. But we
all know how theory and praxis differ...
Anyway, I have attached the new patch (It contains
coreutils-5.2.1-uname-2.patch) in case anyone might find
interesting/nice (or even worthy to be included on some LFS release;
that would be quite gratifying ;-)).
Keep up the good work!
Guillem
- --
Guillem Pagès Gassull
Abt. Neuroinformatik
Fakultät für Informatik
D-89069 Universität Ulm
Germany
email:[EMAIL PROTECTED]
tel:+49 731 50 24245
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (MingW32)
iD8DBQFDae2JqdOjpSDdifMRAtj6AJ4vW3kmItmmmV/GTl5gq6zAvp0I2wCfUkuV
YfJ+SNycoW47tDTCUszGo9k=
=aXpP
-END PGP SIGNATURE-
--- coreutils-5.2.1/src/uname.c 2004-01-21 23:27:02.0 +0100
+++ coreutils-5.2.1-patched/src/uname.c 2005-11-02 15:56:08.0 +0100
@@ -29,6 +29,12 @@
# include sys/systeminfo.h
#endif
+#ifdef linux
+#define cpuid(in,a,b,c,d)\
+ asm(cpuid: =a (a), =b (b), =c (c), =d (d) : a (in));
+int has_sse( void );
+#endif
+
#if HAVE_SYSCTL HAVE_SYS_SYSCTL_H
# include sys/param.h /* needed for OpenBSD 3.0 */
# include sys/sysctl.h
@@ -249,6 +255,115 @@
if (0 = sysinfo (SI_ARCHITECTURE, processor, sizeof processor))
element = processor;
}
+#else
+ {
+ struct utsname u;
+ uname (u);
+ element = u.machine;
+#ifdef linux
+/**
+ *
+ * Hello, major hack. I shouldn't have to do this. struct utsname should
+ * have another element with this info in it. There's probably a struct
+ * somewhere that has this info, I just don't know where it is.
+ *
+ */
+
+ if( !strcmp( element, i586 ) || !strcmp( element, i686 ) ) {
+ int eax, ebx, ecx, edx, unused;
+ int model, family, sse;
+
+ cpuid(0,unused,ebx,ecx,edx);
+ cpuid(1,eax,unused,unused,unused);
+ model = (eax 4) 0xf;
+ family = (eax 8) 0xf;
+
+ switch(ebx) {
+ case 0x756e6547: // Intel
+ switch( family ) {
+ case 5: // Pentium
+ if( model = 3 )
+ element=pentium;
+ if( model 3 )
+ element=pentium-mmx;
+ break;
+ case 6: // PentiumPro - Pentium III
+ if( model == 1 ) // Pentium Pro
+ element=pentiumpro;
+ if( ( model == 3 ) || ( model == 5 ) ||
+ ( model == 6 ) ) // Pentium II
+ element=pentium2;
+ if( ( model == 7 ) || ( model == 8 ) ||
+ ( model == 10 ) || ( model == 11 ) ) // These are all Pentium
III
+ element=pentium3;
+ if( ( model == 9) || ( model == 12 ) ||
+ ( model == 13 ) ) // Pentium-M
+ element=pentium-m;
+ break;
+ case 15: // Pentium4
+ element=pentium4;
+ break;
+ default:
+ break;
+ } // end switch( family )
+ break;
+ case 0x68747541: // AMD
+ switch(family) {
+ case 5:
+ if( ( model == 0 ) || ( model == 1 ) ||
+ ( model == 2 ) || ( model == 3 ) ) // K5
+ element=i586;
+ if( ( model == 6 ) || ( model == 7 ) ) // K6
+ element=k6;
+ if( model == 8 ) // K6-2
+ element=k6-2;
+ if( model == 9 ) // K6-3
+ element=k6-3;
+ break;
+ case 6:
+ if( model = 4 )
+ element=athlon;
+ if( model 4 ) {
+ sse = has_sse();
+ if( sse == 0 )
+ element=athlon;
+ if( sse == 1 )
+ element=athlon-4;
+ }
+ break;
+ case 15:
+ element=athlon-4;
+ break;
+ default:
+ break;
+ } // end switch( family )
+ break;
+ case 0x69727943: // Cyrix
+ element=i386; // who knows what cyrix supports, lets be safe
+ break;
+ case 0x746e6543: // Centaur / VIA
+ switch( family ) {
+
Re: LFS-Bootscripts-3.2.1 setclock
On Thu, Nov 03, 2005 at 09:47:54AM -0100, Duncan Webb wrote: Maybe I was not too clear. No, you were perfectly clear. If the system clock is set to local time then when you shut-down the hardware clock should be set to system time. And again, no. LFS cannot assume the sanity of the system clock so it should not write to the hwclock. NTP gives us the sanity, therefore, NTP is where the symlinks are made. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-Bootscripts-3.2.1 setclock
Bryan Kadzban wrote: On Thu, Nov 03, 2005 at 08:28:12AM -0700, Archaic wrote: On Thu, Nov 03, 2005 at 09:47:54AM -0100, Duncan Webb wrote: Maybe I was not too clear. No, you were perfectly clear. If the system clock is set to local time then when you shut-down the hardware clock should be set to system time. And again, no. LFS cannot assume the sanity of the system clock so it should not write to the hwclock. NTP gives us the sanity, therefore, NTP is where the symlinks are made. This is all true in general, however, I'm starting to think that DST considerations might override that at 2 points during the year. If the user is running NTP, then there's no problem (and as you say, the symlinks are created when NTP is installed). If the user puts their RTC in UTC time, then there's also no problem. (So Duncan, this is your fix: Put your hardware RTC in the UTC timezone, then it won't have to change when DST starts or stops. If you dual boot to less intelligent OSes, then that's a poor fix, but it would at least prevent this problem. Or, set up NTP.) Running a NTP daemon requires a permanent internet connection. Dual boot usually requires the clock in local time, that's clear. What I don't understand is why anybody would have a problem syncing the hardware clock to the system clock at reboot/power off. After all the system clock is synced to the hardware clock at boot. Let's just assume that NTP is /not/ installed, then the clock is manually adjusted once in a while. Without the symlinks you would need to adjust the clock every time the machine is booted or enter the BIOS and fix the time. With the symlinks the hardware clock is adjusted automatically. Having a system with it time being perfectly correct is not essential for all applications, a minute here or there doesn't bother most people. But it is important that time does not jump around. Who want a log where the time at the beginning is later than now. I'm sorry but I just don't see the harm of setting the hardware clock at power off/reboot (with or) without NTP and running in UTC or local time. But if the RTC is in localtime, and localtime changes its offset from UTC, then perhaps the RTC should be offset at that time. It is true that we don't know whether the system clock or the hardware clock is more accurate in general, but if we're talking about an hour difference at DST switchover, the accuracy difference between the system and hardware clocks is likely miniscule in comparison. Note that I have no idea *how* the bootscripts could handle that, just that I think it may be appropriate to set the RTC in this one case. If it's impossible, then that's fine. BTW It can be quite helpful to have a dual boot, if only to check that some bleeding edge hardware driver is doing what it should. Or that some hardware is still working and doesn't have a hardware failure. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-Bootscripts-3.2.1 setclock
On Thu, 3 Nov 2005, Duncan Webb wrote: What I don't understand is why anybody would have a problem syncing the hardware clock to the system clock at reboot/power off. After all the system clock is synced to the hardware clock at boot. In that case, please search the lfs archives and warm yourself by the heat of the discussion. A classic case for your distro, your rules. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-Bootscripts-3.2.1 setclock
On Thu, Nov 03, 2005 at 11:02:49PM -0100, Duncan Webb wrote: Running a NTP daemon requires a permanent internet connection. Dual boot usually requires the clock in local time, that's clear. Absolutely and totally false. Please do your research before making such statements. What I don't understand is why anybody would have a problem syncing the hardware clock to the system clock at reboot/power off. After all the system clock is synced to the hardware clock at boot. I see Ken beat me to the punch WRT to both the your distro, your rules mantra, *and* the relevant discussions of old. When I took over the maintenance of the time hint (http://www.lfs-matrix.org/hints/downloads/files/time.txt) I, too, was of the opinion that the system clock would be more accurate than the hwclock. I was inundated with examples of that not being true and included one such example in the hint itself. Thus, the realization that we cannot assume which is more accurate. BTW, depending on how *you* want to do things, you can either run ntpd manually from time to time or via cron and create the symlinks or forget ntpd altogether. It's completely your call. ;) -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-Bootscripts-3.2.1 setclock
On Fri, Nov 04, 2005 at 12:29:23AM -0100, Duncan Webb wrote: Sort of guessed this by Archaic reaction. Never would have questioned it had the start case not synced to the hardware clock. That's a fair question. However, where would the system clock be initially set if not from the hwclock? That part is mandatory. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Patch for gcc-3.4.x PCH with kernel 2.6.12.x
Hi everyone, This is an old and pretty moot point for LFS, but I thought I'd make a post about it anyway. A few months back, Greg Schafer pointed out that gcc-3.4.x PCH doesn't handle a kernel feature introduced in 2.6.12. Details can be found in this post http://linuxfromscratch.org/pipermail/lfs-dev/2005-July/052312.html. In gcc-4 this issue is resolved. Greg made another post about it here http://linuxfromscratch.org/pipermail/lfs-dev/2005-August/052546.html. This issue was justified with hemorraghing in the gcc testsuite. Well, SVN has moved onto gcc-4, and 6.1 has kernel 2.6.11, so this isn't really relevant anymore. However, I have a sort of SVN system with gcc-3.4.4 and linux-2.6.13.4, so when I compile gcc I get a lot of test failures. This always bugged me, so I went to the gcc commit Greg pointed out and put together a patch for gcc-3.4.4. It works perfectly as far as the tests are concerned. pre-patch: Running /usr/src/build/gcc-3.4.4/gcc/testsuite/gcc.dg/pch/pch.exp ... FAIL: gcc.dg/pch/common-1.c -O3 -g (test for excess errors) FAIL: gcc.dg/pch/common-1.c -Os (test for excess errors) FAIL: gcc.dg/pch/cpp-1.c -O0 (test for excess errors) FAIL: gcc.dg/pch/cpp-1.c -O1 (test for excess errors) FAIL: gcc.dg/pch/cpp-1.c -O2 assembly comparison FAIL: gcc.dg/pch/cpp-2.c -O1 assembly comparison FAIL: gcc.dg/pch/cpp-2.c -O2 (test for excess errors) snip many more pch errors === gcc Summary === # of expected passes25016 # of unexpected failures46 # of expected failures 70 # of untested testcases 46 # of unsupported tests 208 post-patch: Running /usr/src/build/gcc-3.4.4/gcc/testsuite/gcc.dg/pch/pch.exp ... Running /usr/src/build/gcc-3.4.4/gcc/testsuite/gcc.dg/special/mips-abi.exp ... snip === gcc Summary === # of expected passes25167 # of unexpected failures1 # of expected failures 70 # of untested testcases 7 # of unsupported tests 208 (only the common va-arg-25.c -Os fails now) Oops, I forgot to re-test g++. Damn. Anyway, long story long, I'm attaching the patch if anyone's interesed. It's pretty big, so watch out. -- Dan gcc-3.4.4-pch-1.patch.bz2 Description: BZip2 compressed data -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
