Re: Recent Problems with RELENG_7 i386
--- On Wed, 10/8/08, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > From: Jeremy Chadwick <[EMAIL PROTECTED]> > Subject: Re: Recent Problems with RELENG_7 i386 > To: "bf" <[EMAIL PROTECTED]> > 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 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. 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? Regards, b. > -- > | Jeremy Chadwickjdc 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 | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Recent Problems with RELENG_7 i386
--- On Thu, 10/9/08, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > From: Jeremy Chadwick <[EMAIL PROTECTED]> > Subject: Re: Recent Problems with RELENG_7 i386 > To: "bf" <[EMAIL PROTECTED]> > Cc: freebsd-stable@freebsd.org > Date: Thursday, October 9, 2008, 1:12 AM > On Wed, Oct 08, 2008 at 10:00:32PM -0700, bf wrote: > > > > > > > > --- On Wed, 10/8/08, Jeremy Chadwick > <[EMAIL PROTECTED]> wrote: > > > > > From: Jeremy Chadwick <[EMAIL PROTECTED]> > > > Subject: Re: Recent Problems with RELENG_7 i386 > > > To: "bf" <[EMAIL PROTECTED]> > > > 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. :-) Well, actually, with version control, we can -- if we're willing to take the trouble. My local settings haven't changed much, and the load we're talking about is not some pattern lost in the mists of time, but simply booting up. But I'm not suggesting going to any such lengths: the changed behavior occurred after the most recent changes to RELENG_7, in the past two weeks or less. Like you, I haven't taken the time to delve into the inner workings of the kernel, and so I was hoping that someone who had been monitoring RELENG_7's behavior (it's being tested before-and-after commits fairly often during this pre-release freeze, right?) or someone who had made recent changes might be able to narrow it down even further, either by pointing to some changes that might have tipped my machine over the edge at kern.hz=100, or by ruling out FreeBSD changes entirely and pointing the finger at some hardware problem. Some of the related sysctls are: kern.timecounter.tick: 1 kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-100) kern.timecounter.hardware: ACPI-safe kern.timecounter.stepwarnings: 0 kern.timecounter.tc.i8254.mask: 4294967295 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.ACPI-safe.mask: 16777215 kern.timecounter.tc.ACPI-safe.frequency: 3579545 kern.timecounter.tc.ACPI-safe.quality: 850 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.frequency: 906349154 kern.timecounter.tc.TSC.quality: 800 vfs.timestamp_precision: 0 machdep.acpi_timer_freq: 3579545 dev.acpi_timer.0.%desc: 24-bit timer at 3.579545MHz dev.acpi_timer.0.%driver: acpi_timer dev.acpi_timer.0.%location: unknown dev.acpi_timer.0.%pnpinfo: unknown dev.acpi_ti
Re: Recent Problems with RELENG_7 i386
Yes, I disabled device polling on my NIC. It's in my kernel so that I can experiment with it. I use ipfw, but not dummynet. I find your numbers interesting, Ian. But how did you determine when a kern.hz setting was too high or too low -- and was this very sensitive to different workloads? I'd also like to learn more about this subject, and I'm hoping that some of the developers will take the time to include some discussion of this parameter in an updated and expanded tuning(7) manpage. Best wishes for some enjoyable holidays soon, b. --- On Thu, 10/9/08, Charles Sprickman <[EMAIL PROTECTED]> wrote: > From: Charles Sprickman <[EMAIL PROTECTED]> > Subject: Re: Recent Problems with RELENG_7 i386 > To: "Jeremy Chadwick" <[EMAIL PROTECTED]> > Cc: "Ian Smith" <[EMAIL PROTECTED]>, "bf" <[EMAIL PROTECTED]>, > freebsd-stable@freebsd.org > Date: Thursday, October 9, 2008, 2:13 PM > On Thu, 9 Oct 2008, Jeremy Chadwick wrote: > > > On Fri, Oct 10, 2008 at 03:51:02AM +1100, Ian Smith > wrote: > >> > 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. :-) ) > >> > >> You need a day off :) But yes, RELENG_5 still had > HZ=100 default, long > >> after the 'average' CPU clock frequency > was 10 or more times faster than > >> the 166MHz Pentiums and such (mostly then on only > 100Mbps ethernet) that > >> were comfortable at 100Hz slicing. 1000Hz was a > big shift to catch up. > >> > >> In a day or so playing around with it years ago, I > found 200-250Hz good > >> for 300MHz, 500Hz a bit much, 1000Hz way too busy, > and find my 1133MHz > >> P3-M happy enough at 1000Hz, though I've done > no specific tests on it. > >> > >> Some people had perhaps similar clock issues when > their fast processors > >> were throttling/stepping down to very low speeds > (100, even 75MHz) while > >> still slicing at 1000Hz, which I didn't find > too surprising. Limiting > >> minimum CPU freq to 300Mz or more seemed to solve > many such issues, but > >> I haven't your perseverance for digging up the > relevant threads .. > >> > >> Even in 5.5-S (/sys/conf/NOTES and > /sys/i386/conf/NOTES) HZ=1000 or 2000 > >> was suggested for DEVICE_POLLING (which bf > included in config, though > >> maybe it's not enabled?) and HZ=1000 or more > was recommended when using > >> DUMMYNET with ipfw - to provide smoother queue > dispatching, I gather. > >> > >> Bottom line, IMHO, bf should probably run the > default 1000Hz, 500 at > >> least, on an Athlon 900. With powerd, maybe set > min. freq >= 150MHz? > > > > Wow, this is fantastic information. You've just > educated me a great bit > > about the history and use of HZ. I've always had > a "general" idea of > > its importance and key role, but I was never fully > aware of the history. > > Not to pull this too much further OT, but in the original > message there > was a comment about HZ and context switching. I care for a > number of FBSD > boxes that are stuffed full of qmail processes. Context > switches are > always through the roof when the boxes are busy. My > layman's > understanding of "context switching" is very > vague - in short I assume > it's some type of overhead from the kernel having to > move between > servicing different processes. Altering HZ to > "tune" this is very > intriguing to me, so if anyone would like to explain, > I'm all ears. > > > P.S. -- I need more like 6 months off. I've never > taken an official > > (read: real) vacation my entire life. Maybe some day > I'll get to travel > > to Seoul and visit Pyun Yong-Hyeon and drink lots of > soju. :-) > > Join the f***ing club. I'm still waiting for my > honeymoon after two years > of being married. :) > > Charles > > > -- > > | Jeremy Chadwickjdc > 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 | > > > > ___ > > freebsd-stable@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: visibility of release process
I'd also appreciate a little more frequent updating of the release
schedule, maybe with some terse "we're waiting on this ... " notes,
like there were for some past releases. I'd guess the amount of time
involved in doing so would be modest.
> * subversion. Without checking out the whole repository, it is a
> little hard to use this as a news source and emails to the commit list
> still look more like cvs than svn so it is a bit hard to see which
> branch commits are going to. [3]
Other than the comments that have already been made about the
subject and the body of the messages, what's the matter with
the other svn-src-stable-* or other svn-src-* mailing lists, some
of which will focus more closely on those commits affecting the release(s)?
Or, as someone suggested recently on one of the lists, something like:
svn log -v -r '{2008-2-27}:HEAD' svn://svn.freebsd.org/base/stable/7/
Regards,
b.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
