- WLUG - wlug.mailman3.com

Re: [Wlug] orinoco driver

by Andy Stewart

Hi Wes, I discovered on my laptop that I had to insure that my wireless card was listed in /etc/pcmcia/config or things didn't work. (Although I use SuSE 8.0, I believe the description below is distribution agnostic). Try this as root: # cardctl ident Note the "manfid" line. Next, check /etc/pcmcia/config and see if a card with an entry matching the manfid is present. In my case, there was no entry so I added one thus: card "Andy's Linksys Wireless" manfid 0x0274, 0x1613 bind "orinoco_cs" The card string seems to be arbitrary text. The manfid comes from "cardctl ident", and the bind is to a kernel module. I have hotplugging services running, so when I plug in my wireless adapter, it automagically loads the kernel module(s), starts the net, sets up routing, etc. Give it a try and let us know how it goes! Later, Andy -- Andy Stewart, Founder Worcester Linux Users' Group Worcester, MA USA http://www.wlug.org

Aug. 23, 2002

orinoco driver

by Wesley Allen

Hi all, hope the BBQ went well, sorry I couldn't come (I was picking up my Brother-In-Law at Logan...sigh, one day I'll get to a meeting). I've got a netgear wifi card that works great in Mandrake Linux, with the exception of wep (I know, it's cracked). In doing some research on the card and the kernel module that loads wvlan_cs, I have found out that this module has been replaced (by and large) by orinoco_cs, which I understand to be more functional (i.e. maybe I can get wep working?). I tried modprobe -r wvlan_cs and modprobe orinoco_cs but it won't bind to my pcmcia card. So I figured, "Well, maybe my card is just one that can't use the newer driver..." WRONG! Just to see what it was like, I download Knoppix, burned it onto a cd, and booted it up. Guess what driver loaded? orinoco_cs!! And it worked well too. Well, since Knoppix is a cd-boot, run in memory distro; I'm not changing to it anytime soon. So I'm going to use this opportunity to learn something new. How can I bind the orinoco driver to my card? Wes -- This message may be digitally signed. For my public key, e-mail me a request.

Aug. 23, 2002

WLUG BBQ

by Andy Stewart

HI gang, I'm running late. I'm leaving my house now for the BBQ. I'll see ya there around 6:30 - 6:45 PM. Later, Andy -- Andy Stewart, Founder Worcester Linux Users' Group Worcester, MA USA http://www.wlug.org

Aug. 22, 2002

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

by Theo Van Dinter

On Wed, Aug 21, 2002 at 07:33:01PM -0400, Charles R. Anderson wrote: > So let me get this straight...you are using the system clock to measure > the system clock? :) ;) The interrupt change would still be outside the 98 - 102 range if it got funky, but I know what you're saying. I'll test externally after dinner. > The program adjtimex may be interfering in some way. What does > /sbin/adjtimex --print display? <theo installs adjtimex> mode: 0 offset: 16038 frequency: 3138214 maxerror: 148248 esterror: 17792 status: 1 time_constant: 2 precision: 1 tolerance: 33554432 tick: 10000 raw time: 1029973970s 363977us = 1029973970.363977 -- Randomly Generated Tagline: "I sometimes think they choose guards basaed on the bone content of their heads." - Londo on Babylon 5

Aug. 21, 2002

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