Date: Wed, 8 Oct 2008 22:12:14 -0700 From: Jeremy Chadwick <koitsu@FreeBSD.org> To: bf <bf2006a@yahoo.com> Cc: freebsd-stable@freebsd.org Subject: Re: Recent Problems with RELENG_7 i386 Message-ID: <20081009051214.GA94941@icarus.home.lan> In-Reply-To: <501797.33750.qm@web39105.mail.mud.yahoo.com> References: <20081008183652.GA83351@icarus.home.lan> <501797.33750.qm@web39105.mail.mud.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 08, 2008 at 10:00:32PM -0700, bf wrote: > > > > --- On Wed, 10/8/08, Jeremy Chadwick <koitsu@FreeBSD.org> wrote: > > > From: Jeremy Chadwick <koitsu@FreeBSD.org> > > Subject: Re: Recent Problems with RELENG_7 i386 > > To: "bf" <bf2006a@yahoo.com> > > Cc: freebsd-stable@freebsd.org > > Date: Wednesday, October 8, 2008, 2:36 PM > > On Wed, Oct 08, 2008 at 10:19:47AM -0700, bf wrote: > > > After updating to RELENG_7 i386 of this weekend, I > > have been having problems > > > with my machine. When booting normally, the system > > slows or hangs at the > > > login prompt. If I am able to continue past the > > prompt, I sometimes experience > > > erratic mouse behavior, and a subsequent hang, after > > varying lengths of time, > > > even under light workloads. The same problem does not > > seem to occur in > > > single-user mode, and did not occur with the RELENG_7 > > i386 of just over a > > > week ago. I have been unable to obtain crashdumps so > > far, and the only > > > log messages I can find that weren't present > > before are notices like those > > > recorded below: > > > > > > Oct 8 11:00:40 myhost kernel: t_delta > > 15.fd80bdcb75b60200 too short > > > > This comes from src/sys/kern/kern_tc.c, around line 908. > > I'm not > > familiar with the kernel, but two ideas come to mind: > > > > 1) If you have Intel SpeedStep (EIST) or AMD > > Cool'n'Quiet enabled in > > your BIOS, try disabling it, > > > > 2) If you're using powerd, disable it (I don't see > > it enabled), > > > > 3) Try keeping HZ at 1000 (the default). > > > > Thanks, Jeremy, for taking the time to consider my question and reply. > > My CPU is pre-Cool'n'Quiet, and as far as I can tell I had disabled > all forms of power management that may affect the clock speeds. I have > found that by raising kern.hz to 250, or by using the default, I no > longer receive the t_delta is too short messages, and the other problems > are no longer apparent. My question is: why did this occur now? I don't know. We can't rewind time and find out system parameters and kernel details from 6 months ago. :-) I'm thinking it might have something to do with the timecounter selected by the kernel, but as I said, we can't rewind time to find out what things were in the past. The kernel environment variables I'm talking about are kern.timecounter. "sysctl kern.timecounter" could help shed some light here, maybe. It would at least allow us to see what timecounters are available on your system, and if a bad/unreliable one is being selected automatically. > I have been using a similar configuration for months now without any > apparent problems. My original goal in using a lower kern.hz was to > avoid burdening my machine with excessive context switching. This is over my head, technically. I would need to pull John Baldwin into this, since he knows a bit about both (timecounters and context switching). I'm just a simple caveman..... :-) > I saw the relevant section of kern_tc.c before I wrote my first > message, but when skimming through the changes in RELENG_7 over the > past week or two, I couldn't see any commit that may have directly > affected kernel timekeeping. Has some new workload been imposed on > the system by recent changes, that may have made a kern.hz of 100 > insufficient? Is this tuneable setting properly implemented, so that > all parts of the base system are using it's current value rather than > the default? Could some of my hardware, such as my RTC, be > malfunctioning? Well, I believe HZ was increased from 100 to 1000 long ago (RELENG_6?) as a default. I'm really not sure of the implications of decreasing it, besides having less granularity for some things (the only things I know of would be something pertaining to firewalls, I just can't remember what. My brain is full. :-) ) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081009051214.GA94941>