Re: Now: Sweeping generalizations Re: calebs time problem was (Re: MSI motherboards?)
On Sun, May 23, 2004 at 11:02:46PM +1200, Christopher Sawtell wrote: you shouldn't need to ever reboot unless you get a new kernel, If you want to lock up your machine, it's pretty simple. While it's pretty simple to lock up your X-server and keyboard it's now actually very difficult indeed to bring the machine kernel itself to its knees. this brings up memories of me going into the office (10 minute walk) to use ssh to log into my machine at home to kill X. that said, if you have a machine that you do not always have access to, it is not unwise to reboot a machine after evasive changes to make sure the next unattended reboot will go fine. greetings, martin. -- looking for a job doing pike programming, sTeam/caudium/pike/roxen training, sTeam/caudium/roxen and/or unix system administration anywhere in the world. -- pike programmer travelling and working in europeopen-steam.org unix system- bahai.or.at iaeste.(tuwien.ac|or).at administrator (stuts|black.linux-m68k).org is.schon.org Martin Bähr http://www.iaeste.or.at/~mbaehr/
Re: calebs time problem was (Re: MSI motherboards?)
BTW did we get Caleb's time problem fixed? NR
Re: calebs time problem was (Re: MSI motherboards?)
date shown here is 24/5/2004 8:20 am... Caleb Sawtell wrote: On Sun, 23 May 2004 07:57, Nick Rout wrote: On Sun, 2004-05-23 at 19:38, Matthew Gregan wrote: At 2004-05-23T192918+, Caleb Sawtell wrote: On Sun, 23 May 2004 06:20, Nick Rout wrote: ln -sf /usr/share/zoneinfo/Pacific/Auckland /etc/localtime lrwxrwxrwx 1 root root 36 May 23 11:09 /etc/timezone - /usr/share/zoneinfo/Pacific/Auckland seams fine to me... /etc/timezone != /etc/localtime ah [EMAIL PROTECTED]:~$ ls -l /etc/localtime lrwxrwxrwx 1 root root 36 May 23 20:18 /etc/localtime - /usr/share/zoneinfo/Pacific/Auckland [EMAIL PROTECTED]:~$ ok is it fixed?? to be fair I think I put him wrong earlier in the thread. just to finalise this, on gentoo, the link is called /etc/localtime and in this part of the world should point to /usr/share/zoneinfo/Pacific/Auckland http://www.gentoo.org/doc/en/gentoo-x86-quickinstall.xml code listing 1.4 Sorry for the confusion. nrr -mjg
Re: calebs time problem was (Re: MSI motherboards?)
On Mon, 2004-05-24 at 08:20, Caleb Sawtell wrote: On Sun, 23 May 2004 07:57, Nick Rout wrote: On Sun, 2004-05-23 at 19:38, Matthew Gregan wrote: At 2004-05-23T192918+, Caleb Sawtell wrote: On Sun, 23 May 2004 06:20, Nick Rout wrote: ln -sf /usr/share/zoneinfo/Pacific/Auckland /etc/localtime lrwxrwxrwx 1 root root 36 May 23 11:09 /etc/timezone - /usr/share/zoneinfo/Pacific/Auckland seams fine to me... /etc/timezone != /etc/localtime ah [EMAIL PROTECTED]:~$ ls -l /etc/localtime lrwxrwxrwx 1 root root 36 May 23 20:18 /etc/localtime - /usr/share/zoneinfo/Pacific/Auckland [EMAIL PROTECTED]:~$ ok is it fixed?? well not according to this email message, but you might need to reboot... you shouldn't need to ever reboot unless you get a new kernel, but nevertheless I think it might help this time. to be fair I think I put him wrong earlier in the thread. just to finalise this, on gentoo, the link is called /etc/localtime and in this part of the world should point to /usr/share/zoneinfo/Pacific/Auckland http://www.gentoo.org/doc/en/gentoo-x86-quickinstall.xml code listing 1.4 Sorry for the confusion. nrr -mjg
Now: Sweeping generalizations Re: calebs time problem was (Re: MSI motherboards?)
Nick Rout wrote: [snip] you shouldn't need to ever reboot unless you get a new kernel, but nevertheless I think it might help this time. [snip] Come on now... let's get real. Linux isn't perfect, nor is plenty of the software that runs on it. If you want to lock up your machine, it's pretty simple. In this case, it looks like the system time is incorrect. I recommend installing ntpdate, which you run on bootup through a script in /etc/init.d, with its associated symlinks. THis takes care of gross inaccuracies. If you've got an always on connection, which I think you have, you may want to play with ntp, to keep the time synched to millisecond accruacy or better. Once you've done that, you can set yourself up as a tier 3 time server for your local network... and, of course, tommorow, the world (: Steve. Note that as your clock is currently in the future, you may get some strange error messages until it unwinds itself. This will especially manifest itself when compiling code, as the makefiles will be well upset.
Re: Now: Sweeping generalizations Re: calebs time problem was (Re: MSI motherboards?)
On Sunday 23 May 2004 10:50 pm, steve wrote: Nick Rout wrote: [snip] you shouldn't need to ever reboot unless you get a new kernel, but nevertheless I think it might help this time. [snip] Come on now... let's get real. Linux isn't perfect, nor is plenty of the software that runs on it. If you want to lock up your machine, it's pretty simple. While it's pretty simple to lock up your X-server and keyboard it's now actually very difficult indeed to bring the machine kernel itself to its knees. [EMAIL PROTECTED] chris]$ uptime 10:51pm up 86 days, 9:49, 1 user, load average: 0.00, 0.00, 0.00 That's a file, print, and web-server machine. imho it's only just starting the current run. I turned it off because of a thunderstorm. In this case, it looks like the system time is incorrect. I recommend installing ntpdate, which you run on bootup through a script in /etc/init.d, with its associated symlinks. THis takes care of gross inaccuracies. If you've got an always on connection, which I think you have, you may want to play with ntp, to keep the time synched to millisecond accruacy or better. Once you've done that, you can set yourself up as a tier 3 time server for your local network... and, of course, tommorow, the world (: Steve. Note that as your clock is currently in the future, you may get some strange error messages until it unwinds itself. This will especially manifest itself when compiling code, as the makefiles will be well upset. This whole exercise is getting a bit beyond a joke. It has at least shown young Caleb that he does not know everything about hardware clocks. Thank you all for your patience. I will ensure the clock is set correctly tomorrow. -- Sincerely etc. Christopher Sawtell NB. This PC runs Linux. If you find a virus apparently from me, it has forged the e-mail headers on someone else's machine. Please do not notify me when this occurs. Thanks.
Re: calebs time problem was (Re: MSI motherboards?)
On Sun, 23 May 2004 09:26, Nick Rout wrote: On Mon, 2004-05-24 at 08:20, Caleb Sawtell wrote: On Sun, 23 May 2004 07:57, Nick Rout wrote: On Sun, 2004-05-23 at 19:38, Matthew Gregan wrote: At 2004-05-23T192918+, Caleb Sawtell wrote: On Sun, 23 May 2004 06:20, Nick Rout wrote: ln -sf /usr/share/zoneinfo/Pacific/Auckland /etc/localtime lrwxrwxrwx 1 root root 36 May 23 11:09 /etc/timezone - /usr/share/zoneinfo/Pacific/Auckland seams fine to me... /etc/timezone != /etc/localtime ah [EMAIL PROTECTED]:~$ ls -l /etc/localtime lrwxrwxrwx 1 root root 36 May 23 20:18 /etc/localtime - /usr/share/zoneinfo/Pacific/Auckland [EMAIL PROTECTED]:~$ ok is it fixed?? well not according to this email message, but you might need to reboot... you shouldn't need to ever reboot unless you get a new kernel, but nevertheless I think it might help this time. Ok fresh reboot it says the right time on my kde clock (but it has done this whole time) soo if it is not fixed my dad said tha he will help get this prob fixed to be fair I think I put him wrong earlier in the thread. just to finalise this, on gentoo, the link is called /etc/localtime and in this part of the world should point to /usr/share/zoneinfo/Pacific/Auckland http://www.gentoo.org/doc/en/gentoo-x86-quickinstall.xml code listing 1.4 Sorry for the confusion. nrr -mjg
RE: Sweeping generalizations Re: calebs time problem was (Re: MSI motherboards?)
Steve wrote: Come on now... let's get real. Linux isn't perfect, nor is plenty of the software that runs on it. If you want to lock up your machine, it's pretty simple. Well I was telling someone in the weekend that since I built my current box with Gentoo at home 18 months ago I do not recall having one lockup. The guy was telling me that in the same period he has rebuilt his Windows box several times. Rob
RE: Sweeping generalizations Re: calebs time problem was (Re: MSI motherboards?)
On the other hand, I'm still getting plenty of lockups since I installed Gentoo. .. It is definitely improving though as I work my way through various kernel/driver/framebuffer issues. I'm getting there slowly. Quoting Fisher, Robert (FXNZ CHC) [EMAIL PROTECTED]: Steve wrote: Come on now... let's get real. Linux isn't perfect, nor is plenty of the software that runs on it. If you want to lock up your machine, it's pretty simple. Well I was telling someone in the weekend that since I built my current box with Gentoo at home 18 months ago I do not recall having one lockup. The guy was telling me that in the same period he has rebuilt his Windows box several times. Rob
Re: Sweeping generalizations Re: calebs time problem was (Re: MSI motherboards?)
I read somewhere that on your nforce chipset board you should disable either apic or acpi. now if i could find where i saw it. i'd be really useful! On Mon, 24 May 2004 10:27:57 +1200 (NZST) [EMAIL PROTECTED] wrote: On the other hand, I'm still getting plenty of lockups since I installed Gentoo. .. It is definitely improving though as I work my way through various kernel/driver/framebuffer issues. I'm getting there slowly. Quoting Fisher, Robert (FXNZ CHC) [EMAIL PROTECTED]: Steve wrote: Come on now... let's get real. Linux isn't perfect, nor is plenty of the software that runs on it. If you want to lock up your machine, it's pretty simple. Well I was telling someone in the weekend that since I built my current box with Gentoo at home 18 months ago I do not recall having one lockup. The guy was telling me that in the same period he has rebuilt his Windows box several times. Rob -- Nick Rout [EMAIL PROTECTED]
Re: Sweeping generalizations Re: calebs time problem was (Re: MSI motherboards?)
On Mon, 24 May 2004 10:35:06 +1200 Nick Rout [EMAIL PROTECTED] wrote: I read somewhere that on your nforce chipset board you should disable either apic or acpi. now if i could find where i saw it. i'd be really useful! got it, it was a response from the gentoo-dev list in response to a query i made before the installfest. Unfortunatley I didn't see it until afterwards. here is the quote: With the nforce chipset I needed to remove the ACPI and APIC options in the kernel. Using noapic and similar lines didn't disable the kernel. With the ACPI and APIC the machine freezes periodicly. Without those its fantastic. Keep the conversion going ;-) - - -- Daniel Black [EMAIL PROTECTED] Gentoo Embedded Project On Mon, 24 May 2004 10:27:57 +1200 (NZST) [EMAIL PROTECTED] wrote: On the other hand, I'm still getting plenty of lockups since I installed Gentoo. .. It is definitely improving though as I work my way through various kernel/driver/framebuffer issues. I'm getting there slowly.
Re: Now: Sweeping generalizations Re: calebs time problem was (Re: MSI motherboards?)
On Sun, 23 May 2004 22:50:00 +1200 steve [EMAIL PROTECTED] wrote: Nick Rout wrote: [snip] you shouldn't need to ever reboot unless you get a new kernel, but nevertheless I think it might help this time. [snip] Come on now... let's get real. Linux isn't perfect, nor is plenty of the software that runs on it. If you want to lock up your machine, it's pretty simple. yes that was too general. i really meant that you shouldn't have to reboot for a configuration change. usually a daemon can he restarted or HUP'd to accept a new configuration. When i was first running linux i used to reboot to get new changes running, until I discovered the easy way via the /etc/init.d/* scripts. You live and learn. The time stuff is fairly system critical, and I thought it might be better to reboot on this occasion. of course if he was running a critical service, or didn't want to interrupt a long running job, I would look for another solution. In this case, it looks like the system time is incorrect. I recommend installing ntpdate, which you run on bootup through a script in /etc/init.d, with its associated symlinks. THis takes care of gross inaccuracies. If you've got an always on connection, which I think you have, you may want to play with ntp, to keep the time synched to millisecond accruacy or better. Once you've done that, you can set yourself up as a tier 3 time server for your local network... and, of course, tommorow, the world (: Steve. Note that as your clock is currently in the future, you may get some strange error messages until it unwinds itself. This will especially manifest itself when compiling code, as the makefiles will be well upset. -- Nick Rout [EMAIL PROTECTED]
Re: Sweeping generalizations Re: calebs time problem was (Re: MSI motherboards?)
Thanks, I did a bit more googling around just now and found this http://forums.gentoo.org/viewtopic.php?t=169004highlight=nforce2 which has a patch for the problem which will allow me to use acpi and apic. I will have a go at this tonight. Luuk Quoting Nick Rout [EMAIL PROTECTED]: On Mon, 24 May 2004 10:35:06 +1200 Nick Rout [EMAIL PROTECTED] wrote: I read somewhere that on your nforce chipset board you should disable either apic or acpi. now if i could find where i saw it. i'd be really useful! got it, it was a response from the gentoo-dev list in response to a query i made before the installfest. Unfortunatley I didn't see it until afterwards. here is the quote: With the nforce chipset I needed to remove the ACPI and APIC options in the kernel. Using noapic and similar lines didn't disable the kernel. With the ACPI and APIC the machine freezes periodicly. Without those its fantastic. Keep the conversion going ;-) - - -- Daniel Black [EMAIL PROTECTED] Gentoo Embedded Project On Mon, 24 May 2004 10:27:57 +1200 (NZST) [EMAIL PROTECTED] wrote: On the other hand, I'm still getting plenty of lockups since I installed Gentoo. .. It is definitely improving though as I work my way through various kernel/driver/framebuffer issues. I'm getting there slowly.
Re: calebs time problem was (Re: MSI motherboards?)
Ok fresh reboot it says the right time on my kde clock (but it has done this whole time) soo if it is not fixed my dad said tha he will help get this prob fixed I had something similar with my gentoo install, until I modified /etc/rc.conf as below. # Set CLOCK to UTC if your system clock is set to UTC (also known as # Greenwich Mean Time). If your clock is set to the local time, then set CLOCK # to local. This setting is used by the /etc/init.d/clock script. #CLOCK=UTC CLOCK=local I think you find the shutdown scripts saves the time to the hardware clock as per that setting? Cheers. Col.
RE: calebs time problem was (Re: MSI motherboards?)
This was suggested to Caleb early on in the thread. Did you check it Caleb? Regards, Robert Some days you are the pigeon, some days you are the statue. -Original Message- From: Col [mailto:[EMAIL PROTECTED] Sent: Monday, 24 May 2004 1:07 p.m. To: [EMAIL PROTECTED] Subject:Re: calebs time problem was (Re: MSI motherboards?) Ok fresh reboot it says the right time on my kde clock (but it has done this whole time) soo if it is not fixed my dad said tha he will help get this prob fixed I had something similar with my gentoo install, until I modified /etc/rc.conf as below. # Set CLOCK to UTC if your system clock is set to UTC (also known as # Greenwich Mean Time). If your clock is set to the local time, then set CLOCK # to local. This setting is used by the /etc/init.d/clock script. #CLOCK=UTC CLOCK=local I think you find the shutdown scripts saves the time to the hardware clock as per that setting? Cheers. Col.
Re: Sweeping generalizations Re: calebs time problem was (Re: MSI motherboards?)
Nick Rout wrote: I read somewhere that on your nforce chipset board you should disable either apic or acpi. On Mon, 24 May 2004 10:27:57 +1200 (NZST) [EMAIL PROTECTED] wrote: On the other hand, I'm still getting plenty of lockups since I installed Gentoo. .. It is definitely improving though as I work my way through various kernel/driver/framebuffer issues. I'm getting there slowly. By and large, regular lockups (i.e. kernel panic/oops, not just X getting its knickers in a twist) only happens on: 1. faulty hardware 2. incorrect BIOS settings 3. new/exotic hardware I once installed Linux on a machine that had been running Windows 95 (This was some time ago, maybe about Linux 1.2). I was getting a kernel oops a couple of times a day. It turned out to be overly aggressive memory timings in the BIOS. Nobody had noticed on Windows 95 - crashes were normal. Cheers, Carl.
Re: calebs time problem was (Re: MSI motherboards?)
On Mon, 24 May 2004 13:07:06 +1200 Col [EMAIL PROTECTED] wrote: Ok fresh reboot it says the right time on my kde clock (but it has done this whole time) soo if it is not fixed my dad said tha he will help get this prob fixed I had something similar with my gentoo install, until I modified /etc/rc.conf as below. # Set CLOCK to UTC if your system clock is set to UTC (also known as # Greenwich Mean Time). If your clock is set to the local time, then set CLOCK # to local. This setting is used by the /etc/init.d/clock script. #CLOCK=UTC CLOCK=local I think you find the shutdown scripts saves the time to the hardware clock as per that setting? thats right, the script is /etc/init.d/clock. It is in the boot runlevel, which comes up before the default runlevel. on startup it runs with the start parameter, and reads the hardware clock. It interprets that as either UTC or localtime depending on whats in /etc/rc.conf. It sets the internal software system time (which in unix is UTC) accordingly. The time seen by userland programs like mail clients or the date program is converted from the internal software unix UTC clock by referring to /etc/localtime. when the system shuts down the /etc/init.d/clock script runs with the stop parameter, which saves the time back to the hardware clock. It stores it in the hardware clock as UTC or localtime depending what is in /etc/rc.conf, ie the same decision it made on starting. If you run a linux only system you can set /etc/rc.conf to UTC or localtime.[1] Windows on the other hand expects the hardware clock to be set to localtime, so if you dualboot you should choose the localtime option in /etc/rc.conf, so the time will be the same in linux and windows. [1] If you think about it, it doesn't matter to linux whether you store the time on the hardware clock as local or UTC, as it can work out from the configuration setting you gave it in /etc/rc.conf, and as long as you are consistent. Cheers. Col. -- Nick Rout [EMAIL PROTECTED]