Well - I've discovered that the SCX200 HRT and SCX200 watchdog that exist in the older Geode GX processors found on my net4826 boards are no longer present on the Geode LX800 that comes with the net5501.
So the only gain I've gotten w/ the custom kernel is the ticks back to 250 hz (for some reason the latest fedora errata kernel 2.6.22.7-57 went to a 1000hz timer which I don't need). I'm running on the PIT timer with a clocksource=pit kernel command line option since it keeps flagging the TSC unstable and falling back on the PIT anyway. It seems to be keeping time pretty well (will allow ntp updates to go overnight to see how it does), so I think I'm going to move on and just use it w/o any special hardware hi-res timer support. I've noticed the Geode hardware AES support is there along with the hardware random number generator: geode-aes: GEODE AES engine enabled. AMD Geode RNG detected I suppose these are more useful than the 27mhz clock -- especially for VPN type setups where the encryption can be accelerated by the hardware for which this box will be doing that. (need to find out what will actually take advantage of it). Hopefully all clock related issues are overwith -- it's looking that way. > I got in touch w/ Soren on this. > > Some boards have this problem, recent ones should not. > Mine is of the variety that has the problem (obviously). > > There are two capacitors under crystal X3 on the board that > need to be replaced with 22pf NP0 0603 case parts. > > They are right below the X3 crystal (look on the silkscreen > and the X3 crystal is clearly labelled). They are side-by-side. > > We happened to have some in stock and did the mod ourselves > saving sending the board back. This did the trick nicely -- > the "time" command in the bios shows the clock ticking properly > and the system clock under linux ticks just fine whether using > the TSC based clocksource or the PIT clocksource (at least > with stock Fedora core 6 kernel 2.6.18. I've found the latest > errata kernel 2.6.22.7-57 declares the TSC unstable and falls > back to the PIT timer, not sure why) > > I'm in the process of building a new kernel where I've enabled > the scx200_hrt support along with turning the HZ value back > to 250 instead of 1000 to cut down on the number of PIT > interrupts. My plan is to try booting w/ clocksource=scx200_hrt > to take advantage of the 27mhz clock specific to the geode. > > > > > Hello all- > > > > I've been reading the list archives to find it appears some people have > > reported an exessively fast hardware clock and system clock on the 5501. > > > > This includes mine. I've found I can use clock=pit on my fedora core 6 > > install stock kernel to at least get the system clock to calm down. > > > > I've read about building in support for the scx200 high speed hardware > > counter to have the kernel use that instead of the TSC. I plan to > > use that to solve system clock issues permanently. Apparently it's > > when the TSC is in use (w/ the new tickless 2.6 kernel stuff) that > > the system clock side of it gets in trouble. > > > > But the hardware clock running too fast still persists. I've read > > others who have watched it from Comm BIOS with the "time" command > > to see it in action. I've used hwclock from linux to see it going > > too fast when compared w/ my system clock running with the PIT > > timer. > > > > I've also read that it seems some people have this problem and > > others don't? I could be wrong, but is this true that some > > boards have the fast hardware clock problem and others don't? > > > > Is there something that can be done to correct this? That's the > > one thing I couldn't find in the archives, so I'm asking about it > > here. I really want to avoid having a clock that gets ahead when > > this box needs to get it's initial system clock setup from the > > hardware clock at boot. It will be annoying to have ntpdate or > > rdate push it backwards in time once the network is started etc. > > > > So -- is there a fix available even if it means modifying the > > hardware? I'd be happy to send the board back for re-work > > and would even consider paying for the shipping etc. as it's > > simply important to me to have this fixed. I'm also willing > > to have one of our techs replace a crystal or whatever if it > > means changing something physical. > > > > Otherwise -- so far it's looking good for my planned use as a > > firewall / router / no moving parts / lower power frontend > > to our couple of internet connections and wireless network. > > > > Any info would be greatly appreciated. > > > > -- > > Eric Malkowski > > > _______________________________________________ Soekris-tech mailing list [email protected] http://lists.soekris.com/mailman/listinfo/soekris-tech
