- WLUG - wlug.mailman3.com

Re: [Wlug] Stupid Hardware Clock Tricks, aka: WTF?

by Charles R. Anderson

On Wed, Aug 21, 2002 at 07:15:14PM -0400, Theo Van Dinter wrote: felicity> That's about right, a quick 'while(1){grep ' 0' /proc/interrupts;sleep felicity> 1}' shows ~101 per second, with the overhead of doing the fork/grep... So let me get this straight...you are using the system clock to measure the system clock? :) I suggest writing down the value, counting five minutes with an EXTERNAL clock, such as a stopwatch, and then writing down the value again. (value2 - value1) / (60*5) should equal about 100. Of course, I don't see how a skew in the timer tick could cause the system time to change by a whole hour... There is also the possiblity of adjtime screwing up. There are syscalls related to adjusting the system clock used by NTP et. al. and I remember reading that xntpd had to keep up with changes between kernel revisions, or weird time setting issues would result. The program adjtimex may be interfering in some way. What does /sbin/adjtimex --print display? -- Charles R. Anderson <cra(a)wpi.edu> / http://angus.ind.wpi.edu/~cra/ PGP Key ID: 49BB5886 Fingerprint: EBA3 A106 7C93 FA07 8E15 3AC2 C367 A0F9 49BB 5886

Aug. 21, 2002

Re: [Wlug] Stupid Hardware Clock Tricks, aka: WTF?

by Theo Van Dinter

On Wed, Aug 21, 2002 at 06:37:25PM -0400, Charles R. Anderson wrote: > The hardware clock is only read during boot, so that couldn't be it... hmmm. > The system clock keeps time by the system timer interrupt, I believe. The > timer interrupt is generated by the system's RTC chip. On x86 platforms > it is fixed at 100 Hz (only Alpha uses a different value--1024 Hz). I > remember reading that the HZ timer could be changed on any platform now, > but maybe that was for 2.5 only. That's about right, a quick 'while(1){grep ' 0' /proc/interrupts;sleep 1}' shows ~101 per second, with the overhead of doing the fork/grep... > Take a look at IRQ 0 in /proc/interrupts. Take a sampling of values over > time, and figure out how many interrupts there are per second. Maybe > that will shed some light on this... I have a script checking per second and reporting if the differences is 90 > diff > 110. I figure a 2% skew in a second isn't horribly bad. Over 5 minutes, and nothing was displayed. :( -- Randomly Generated Tagline: "BUGS: This manpage is confusing." - man page for getopt

Aug. 21, 2002

Re: [Wlug] Stupid Hardware Clock Tricks, aka: WTF?

by Michelle Vadeboncoeur

On Wed, 21 Aug 2002, Michael Frysinger wrote: MF> i run 2.4.1{6,8}-xfs w/out any time issues MF> (so as to dispell the source of the problem being kernel) MF> MF> From: "Theo Van Dinter" <felicity(a)kluge.net> MF> > BTW: If anyone is wondering, I'm running SGI's XFS patched 2.4.18 kernel: MF> > 2.4.18-SGI_XFS_1.1. I'm thinking about dropping back to a 2.4.9 kernel MF> > w/ XFS support and seeing if that works any better. :( I was running MF> > 2.4.18 on the P200 for quite a while though without problem. the kernel didn't change, so that's not likely the problem... (I did try to warn Theo to not change too many things at once, but... still did the hardware upgrade at the same time as the RH7.2->7.3 upgrade... <sigh>) -- --==*==-- --==*==-- Michelle R. Vadeboncoeur --==*==-- --==*==-- mrv(a)kluge.net: http://www.kluge.net/~mrv/

Aug. 21, 2002

Re: [Wlug] Stupid Hardware Clock Tricks, aka: WTF?

by Charles R. Anderson

On Wed, Aug 21, 2002 at 05:31:28PM -0400, Theo Van Dinter wrote: felicity> I've tried "hwclock --systohc" to force the hardware clock to the same felicity> time as the system, didn't help. I'm running NTP and thought maybe The hardware clock is only read during boot, so that couldn't be it... The system clock keeps time by the system timer interrupt, I believe. The timer interrupt is generated by the system's RTC chip. On x86 platforms it is fixed at 100 Hz (only Alpha uses a different value--1024 Hz). I remember reading that the HZ timer could be changed on any platform now, but maybe that was for 2.5 only. So, I wonder if it has something to do with the timer interrupt? Take a look at IRQ 0 in /proc/interrupts. Take a sampling of values over time, and figure out how many interrupts there are per second. Maybe that will shed some light on this... -- Charles R. Anderson <cra(a)wpi.edu> / http://angus.ind.wpi.edu/~cra/ PGP Key ID: 49BB5886 Fingerprint: EBA3 A106 7C93 FA07 8E15 3AC2 C367 A0F9 49BB 5886

Aug. 21, 2002

Re: [Wlug] Stupid Hardware Clock Tricks, aka: WTF?

by Michael Frysinger

i run 2.4.1{6,8}-xfs w/out any time issues (so as to dispell the source of the problem being kernel) -mike ----- Original Message ----- From: "Theo Van Dinter" <felicity(a)kluge.net> To: "Worcester Linux User's Group" <wlug(a)wlug.org> Sent: Wednesday, August 21, 2002 17:31 Subject: [Wlug] Stupid Hardware Clock Tricks, aka: WTF? > Over this past weekend I upgraded my server from a P200/RedHat Linux > 7.2 to a new Athlon 850/RedHat Linux 7.3. The Athlon was my trusty > workstation for many a year. Everything's great, except for one problem: > the clock goes crazy! > > It seems to be a once per second issue: > > $ perl -e '$t=time;while(1){$t2=time; warn join("\n",scalar > localtime($t),scalar localtime($t2),"") if ($t2-$t>4); $t=$t2;}' > Wed Aug 21 17:17:28 2002 > Wed Aug 21 18:29:03 2002 > Wed Aug 21 17:17:29 2002 > Wed Aug 21 18:29:04 2002 > Wed Aug 21 17:17:30 2002 > Wed Aug 21 18:29:05 2002 > > > I use netsaint to monitor system health, and it keeps complaining about > the time jumps: > > Aug 21 18:28:03 eclectic netsaint: Warning: A system time change of 4296 > seconds (forwards in time) has been detected. Compensating... > Aug 21 17:16:31 eclectic netsaint: Warning: A system time change of 4293 > seconds (backwards in time) has been detected. Compensating... > Aug 21 18:29:42 eclectic netsaint: Warning: A system time change of 4296 > seconds (forwards in time) has been detected. Compensating... > Aug 21 17:18:10 eclectic netsaint: Warning: A system time change of 4293 > seconds (backwards in time) has been detected. Compensating... > > Of course, random checks start failing as well since they occasionally > run during the time jump, and if they're checking for time since something > occured (log entry, cron run, query response time, etc) ... > > I've tried "hwclock --systohc" to force the hardware clock to the same > time as the system, didn't help. I'm running NTP and thought maybe > it was having problems, so I tried turning that off, didn't help. > I went through BIOS and tweaked memory/IRQ settings -- I didn't think > it would really solve anything, but the setting changes and reboot kept > the behavior away for ~14-15 hours. > > > So I'm completely stumped as to what causes this problem. Has anyone > seen anything like this before? Any suggestions for things to look at? > I'm at the point where I'm planning to just buy a new bit of hardware, > migrate the drives and such again, and go from there. With my luck the > problem would follow me of course... :( > > Thanks in advance. :) > > BTW: If anyone is wondering, I'm running SGI's XFS patched 2.4.18 kernel: > 2.4.18-SGI_XFS_1.1. I'm thinking about dropping back to a 2.4.9 kernel > w/ XFS support and seeing if that works any better. :( I was running > 2.4.18 on the P200 for quite a while though without problem. > > -- > Randomly Generated Tagline: > I don't want to look like a weirdo. I'll just go with a muumuu. > > -- Homer Simpson > King-Size Homer > > _______________________________________________ > Wlug mailing list > Wlug(a)mail.wlug.org > http://mail.wlug.org/mailman/listinfo/wlug >

Aug. 21, 2002

Stupid Hardware Clock Tricks, aka: WTF?

by Theo Van Dinter

Over this past weekend I upgraded my server from a P200/RedHat Linux 7.2 to a new Athlon 850/RedHat Linux 7.3. The Athlon was my trusty workstation for many a year. Everything's great, except for one problem: the clock goes crazy! It seems to be a once per second issue: $ perl -e '$t=time;while(1){$t2=time; warn join("\n",scalar localtime($t),scalar localtime($t2),"") if ($t2-$t>4); $t=$t2;}' Wed Aug 21 17:17:28 2002 Wed Aug 21 18:29:03 2002 Wed Aug 21 17:17:29 2002 Wed Aug 21 18:29:04 2002 Wed Aug 21 17:17:30 2002 Wed Aug 21 18:29:05 2002 I use netsaint to monitor system health, and it keeps complaining about the time jumps: Aug 21 18:28:03 eclectic netsaint: Warning: A system time change of 4296 seconds (forwards in time) has been detected. Compensating... Aug 21 17:16:31 eclectic netsaint: Warning: A system time change of 4293 seconds (backwards in time) has been detected. Compensating... Aug 21 18:29:42 eclectic netsaint: Warning: A system time change of 4296 seconds (forwards in time) has been detected. Compensating... Aug 21 17:18:10 eclectic netsaint: Warning: A system time change of 4293 seconds (backwards in time) has been detected. Compensating... Of course, random checks start failing as well since they occasionally run during the time jump, and if they're checking for time since something occured (log entry, cron run, query response time, etc) ... I've tried "hwclock --systohc" to force the hardware clock to the same time as the system, didn't help. I'm running NTP and thought maybe it was having problems, so I tried turning that off, didn't help. I went through BIOS and tweaked memory/IRQ settings -- I didn't think it would really solve anything, but the setting changes and reboot kept the behavior away for ~14-15 hours. So I'm completely stumped as to what causes this problem. Has anyone seen anything like this before? Any suggestions for things to look at? I'm at the point where I'm planning to just buy a new bit of hardware, migrate the drives and such again, and go from there. With my luck the problem would follow me of course... :( Thanks in advance. :) BTW: If anyone is wondering, I'm running SGI's XFS patched 2.4.18 kernel: 2.4.18-SGI_XFS_1.1. I'm thinking about dropping back to a 2.4.9 kernel w/ XFS support and seeing if that works any better. :( I was running 2.4.18 on the P200 for quite a while though without problem. -- Randomly Generated Tagline: I don't want to look like a weirdo. I'll just go with a muumuu. -- Homer Simpson King-Size Homer

Aug. 21, 2002

Red Hat, Westford MA career day

by Tim Burke

FYI - we're having an open house next Wednesday. http://bostonworks.boston.com/events/openhouses/redhat.shtml

Aug. 20, 2002

Re: [Wlug] REMINDER: WLUG BBQ

by desdinova＠soupforare.net

On 17 Aug 2002 at 20:59, Andy Stewart wrote: > > HI everybody, > > The WLUG BBQ will be held on Thursday, August 22nd starting at 6 PM. > Directions to Doug Waud's house, a.k.a BBQ Central, can be found on > the WLUG website. > > Please RSVP if you plan to attend. I've received 3 or 4 RSVPs and I'm > sure there will be more people than that. We need to have an idea how > much food to purchase. Je responde. That's the correct RSVP, isn't it? I don't remember my french teachings :) Thanks James KB1FJQ

Aug. 18, 2002

REMINDER: WLUG BBQ

by Andy Stewart

HI everybody, The WLUG BBQ will be held on Thursday, August 22nd starting at 6 PM. Directions to Doug Waud's house, a.k.a BBQ Central, can be found on the WLUG website. Please RSVP if you plan to attend. I've received 3 or 4 RSVPs and I'm sure there will be more people than that. We need to have an idea how much food to purchase. WLUG will supply the standard BBQ fare and some soda and munchies. If you want beer or wine, you may BYOB and we'll have a way to keep it cold. Feel free to bring your own dessert or cold salad items if you so choose. Doug's house has a pool so bring towels and such! If you can think of anything else, let me know. Otherwise, I'll see you all on Thursday. Later, Andy -- Andy Stewart, Founder Worcester Linux Users' Group Worcester, MA USA http://www.wlug.org

Aug. 18, 2002

Kernel int-13 interface?

by Chuck Homic

Hey, this one goes out to all you kernel hackers out there. After 4 years, I've once again become interested in installing Linux on my HP OmniBook 300. Because it's an aswesome computer, and I think DOS 5 is a complete waste of its skill. [Background. The OB300 is a vintage 386-20, with a passive reflective 640x480 LCD display. Basically an oversize TI calculator running DOS] Anyway, from my first tests, I discovered that I can indeed boot the kernel using loadlin. But it immediately freaks out because it can't read (or even think about) my primary media... solid-state PCMCIA flash cards. Now, I briefly tried looking up some data on the OB300's PCMCIA chipset (I think the first standard was still being developed when this computer was made) and quickly decided that wasn't the route to go. And HP told me to go to hell when I asked. But DOS seems to work just fine using the int 13 interface to access the flash disks. So now my question... can I do that in Linux? I don't see any block device support (and most people would agree an int 13 block device would be stupid), but I think I can write one myself. All it would have to do is make the switch into real mode, call the int 13 interface, and then come back. Will Linux tolerate that? As far as I know, many drivers use a real mode interrupt on laptops to trigger their power saving capabilities (suspend, etc...), so I suspect it would be okay. Can anyone stop me before I go too far? Or should I go ahead and write this thing? -Chuck

Aug. 16, 2002