Re: Interrupt storm with shared interrupt on digi(4)
* John Baldwin <[EMAIL PROTECTED]> [080604 11:12] wrote: > On Tuesday 03 June 2008 03:04:18 pm Peter Jeremy wrote: > > BTW, your MUA's list-reply configuration don't recognize that > > freebsd-stable@ and stable@ are aliases. > > Yes, kmail is broken and the authors refuse to fix it. It happens on reply > to > a foo@ e-mail (it changes the 'To' to 'freebsd-foo@' because of the List-Id > header and leaves foo@ in the 'CC' field). Note that there isn't anything in > the List headers that says that foo@ is an alias for [EMAIL PROTECTED] I > just > wish I could turn off the List-Id crap and use plain old reply-to-all, but > that is where the kmail developers disagree. wtf.why not just have a checkbox to toggle the behavior? -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Wed, 04 Jun 2008 22:19:03 -0700 Jo Rhett <[EMAIL PROTECTED]> wrote: > Edwin, I've been building testbed environments for over 20 years in > my professional career. I know a lot more than this basic concept. > > The costs in our environment for a proper testbed is $20k in > hardware and 3000 man hours. That's for a small test of comparable > small changes to the existing environment. > > Why would we take on this cost only to re-document well known and > already acknowledged bugs? I mean, really? I'm surprised that a test environment (for upgrade testing, load testing, release testing) isn't already in place. Some people (customers and operators alike) might think it is unprofessional and unsafe to run a production system without a test system available. If you have a test system available, why don't you use it? -- Regards, Torfinn Ingolfsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
I'm going to be offline for a week starting now, so please don't read my lack of answers as anything other than "out of town". Sorry. For clarity: I'm not asking for anyone to fix anything. I honestly believe most developers are addressing problems as fast as they can. I'd help them in any way I could. I am suggesting that given that the current bug list for 6.3-RELEASE is both (a) too large and (b) breaks things that work fine in 6.2 ... that I think pushing 6.2 (the real stable release) into EoL is a bit rushed. I sympathize with the development costs of maintaining old versions. Again, I will help in any way I can. On my return next week I would happily build and provide 6.3-RELEASE systems for any developer who needs a test environment for reported bugs that affect hardware I have in my possession. Free boxes, free bandwidth, power, etc. No problem. Free my time in whatever way I can help. But until such time as the current bug list for 6.3 hardware reduces to somewhere less than 100% likelyhood of experiencing failures after an upgrade, there's just no way I can take our production environment forward. Going "bravely forward" to guaranteed failure isn't a great way to enjoy your job :-( Which means I'll be doing our security patches by hand. Because it may be time intensive, but it's less likely to cause a production failure. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 4, 2008, at 5:44 PM, Scott Long wrote: Really, if it's such a big issue that you have time to bitch an moan on the mailing lists, I don't understand why you don't have time to also help a goddamned developer identify the problem. Are you actually experiencing problems with 6.3, or not? None of the bugs were in a state with the developer trying to identify the system. We have several systems dedicated for FreeBSD developers to use for test cases already, and we'd be happy to provide another if one was necessary. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 4, 2008, at 5:48 PM, Max Laier wrote: Because the people who support FreeBSD 6.2 are also knee-deep in major projects of their own!? We try try to not introduce regressions as we move forward supporting new features and hardware, but unless people put in some effort of their own helping us to test ... You obviously did not put in any effort of your own so why would you expect us to do the work for you? Unless you can provide "*EXACT*" bug reports and show willingness to help debugging them, there really is not much point in this thread. The bugs in question were very well documented. None of them were in a state indicating that the developer could not reproduce nor were they waiting for more info.Given that situation, I didn't see a need to add more to a known problem. *IF* any of them had been looking for test cases, I would have been happy to build a test system and turn it over to the developer in question. We do that fairly routinely. And please stop with the loaded language. I'm not asking anyone to work for me. I am suggesting that it is perhaps too early to EoL 6.2 because 6.3 isn't ready yet. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 4, 2008, at 5:35 PM, Edwin Groothuis wrote: Use the eat-your-own-food approach (while not knowing what the 500 systems do): Make sure you use the same hardware and software as what is in production. Upgrade it first, run it for two weeks. If it doesn't, fallback and see where it went wrong. If it all works fine after two weeks, roll it out. Edwin, I've been building testbed environments for over 20 years in my professional career. I know a lot more than this basic concept. The costs in our environment for a proper testbed is $20k in hardware and 3000 man hours. That's for a small test of comparable small changes to the existing environment. Why would we take on this cost only to re-document well known and already acknowledged bugs? I mean, really? Not trying to be sarcastic, but do you purchase cars to test them out and see if you can get better gas mileage than the EPA observes? Neither do I ;-) (yes, their testing methodology is flawed but it's a decent enough benchmark to know if you want the vehicle or not) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 4, 2008, at 5:30 PM, Steven Hartland wrote: That's unfortunate. One thing you might want to check is are there any changes in those areas between 6.2 and 6.3 e.g. if its a bug with a specific driver but said driver has had no commits or not commits in the specific area then it may be fairly safe to conclude said bug also exists in 6.2 and if you haven't seen it there your unlikely to experience it in 6.3. The bugs in question are *not* replicable in 6.2, and each of the bug reports has said so. This is the major point of concern for us. What happened between 6.2 and 6.3 to break so many drivers? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
If this is so important to you - contribute to the project and/or hire a FreeBSD developer. (Ah, the Curse of Open Source Projects..) Adrian 2008/6/5 Jo Rhett <[EMAIL PROTECTED]>: > > On Jun 4, 2008, at 5:17 PM, Steven Hartland wrote: >> >> I wouldn't be surprised if these are not new bugs, just something >> that others have noticed later than 6.2 and I'd suggest you actually >> try 6.3 to see if they are in fact an issue for you. > > I don't have the resources to load up the systems enough to find these > problems sitting on my desk. And I can't risk production resources for > problems known and reported on the *EXACT* same hardware. > > "oh but it won't happen to me" isn't a useful methodology in a production > environment. > > I mean, seriously, I know the majority of you are happy rebooting your > systems 5x daily to run the latest. I'll do that with my home system, no > problem. But I can't do this in a production environment. > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source and > other randomness > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- Adrian Chadd - [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: challenge: end of life for 6.2 is premature with buggy 6.3
On Thursday 05 June 2008 02:26:29 Jo Rhett wrote: > On Jun 4, 2008, at 5:05 PM, Scott Long wrote: > > Jo Rhett wrote: > >> On Jun 4, 2008, at 12:00 PM, Scott Long wrote: > >>> Can you describe the bugs that are affecting you? > >> > >> gmirror failures, 3ware raid driver timeouts, bge0 problems. All > >> three in production use on dozens of systems. > > > > Give me specific details on the 3ware and bge problems. > > Familiar with searching the open bug reports? That's where I found > them. > > Sorry, I'm knee-deep in a major project that I've been working 16+ > hours a day on right now, and I just don't have the time for spurious > queries. Query the open bug reports for 6.3 and then explain to me > again why 6.2 is no longer supported. Because the people who support FreeBSD 6.2 are also knee-deep in major projects of their own!? We try try to not introduce regressions as we move forward supporting new features and hardware, but unless people put in some effort of their own helping us to test ... You obviously did not put in any effort of your own so why would you expect us to do the work for you? Unless you can provide "*EXACT*" bug reports and show willingness to help debugging them, there really is not much point in this thread. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
Jo Rhett wrote: On Jun 4, 2008, at 5:05 PM, Scott Long wrote: Jo Rhett wrote: On Jun 4, 2008, at 12:00 PM, Scott Long wrote: Can you describe the bugs that are affecting you? gmirror failures, 3ware raid driver timeouts, bge0 problems. All three in production use on dozens of systems. Give me specific details on the 3ware and bge problems. Familiar with searching the open bug reports? That's where I found them. Sorry, I'm knee-deep in a major project that I've been working 16+ hours a day on right now, and I just don't have the time for spurious queries. Query the open bug reports for 6.3 and then explain to me again why 6.2 is no longer supported. Really, if it's such a big issue that you have time to bitch an moan on the mailing lists, I don't understand why you don't have time to also help a goddamned developer identify the problem. Are you actually experiencing problems with 6.3, or not? Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Wed, Jun 04, 2008 at 05:24:42PM -0700, Jo Rhett wrote: > On Jun 4, 2008, at 5:17 PM, Steven Hartland wrote: > >I wouldn't be surprised if these are not new bugs, just something > >that others have noticed later than 6.2 and I'd suggest you actually > >try 6.3 to see if they are in fact an issue for you. > > I don't have the resources to load up the systems enough to find these > problems sitting on my desk. And I can't risk production resources > for problems known and reported on the *EXACT* same hardware. > > "oh but it won't happen to me" isn't a useful methodology in a > production environment. > > I mean, seriously, I know the majority of you are happy rebooting your > systems 5x daily to run the latest. I'll do that with my home system, > no problem. But I can't do this in a production environment. Use the eat-your-own-food approach (while not knowing what the 500 systems do): Make sure you use the same hardware and software as what is in production. Upgrade it first, run it for two weeks. If it doesn't, fallback and see where it went wrong. If it all works fine after two weeks, roll it out. Edwin -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://www.mavetju.org/weblog/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
- Original Message - From: "Jo Rhett" <[EMAIL PROTECTED]> On Jun 4, 2008, at 5:17 PM, Steven Hartland wrote: I wouldn't be surprised if these are not new bugs, just something that others have noticed later than 6.2 and I'd suggest you actually try 6.3 to see if they are in fact an issue for you. I don't have the resources to load up the systems enough to find these problems sitting on my desk. And I can't risk production resources for problems known and reported on the *EXACT* same hardware. "oh but it won't happen to me" isn't a useful methodology in a production environment. I mean, seriously, I know the majority of you are happy rebooting your systems 5x daily to run the latest. I'll do that with my home system, no problem. But I can't do this in a production environment. That's unfortunate. One thing you might want to check is are there any changes in those areas between 6.2 and 6.3 e.g. if its a bug with a specific driver but said driver has had no commits or not commits in the specific area then it may be fairly safe to conclude said bug also exists in 6.2 and if you haven't seen it there your unlikely to experience it in 6.3. Without any specifics people will be unable to comment. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.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: challenge: end of life for 6.2 is premature with buggy 6.3
- Original Message - From: "Jo Rhett" <[EMAIL PROTECTED]> I'm sorry to hear that. Our servers have never hung with 6.2. Reboots only occurred to satisfy kernel security patches. But with 6.3 there are many open bug reports about our exact hardware, and I'd prefer to avoid swapping positions with you ;-0 I wouldn't be surprised if these are not new bugs, just something that others have noticed later than 6.2 and I'd suggest you actually try 6.3 to see if they are in fact an issue for you. We have been very happy with 6.2 here and we have quite a few machines using it. Apart from the very occasional crash when odd things like multi disk failures, they have all be solid. We won't however be upgrading to 6.3, instead we are moving to 7.0 which has again has been proved very stable here, but has the add benefit of a large amount of improvements especially in SMP performance. You may wish to consider this as an alternative after validation with your hardware / software of course :) Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.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: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 4, 2008, at 5:05 PM, Scott Long wrote: Jo Rhett wrote: On Jun 4, 2008, at 12:00 PM, Scott Long wrote: Can you describe the bugs that are affecting you? gmirror failures, 3ware raid driver timeouts, bge0 problems. All three in production use on dozens of systems. Give me specific details on the 3ware and bge problems. Familiar with searching the open bug reports? That's where I found them. Sorry, I'm knee-deep in a major project that I've been working 16+ hours a day on right now, and I just don't have the time for spurious queries. Query the open bug reports for 6.3 and then explain to me again why 6.2 is no longer supported. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 4, 2008, at 5:17 PM, Steven Hartland wrote: I wouldn't be surprised if these are not new bugs, just something that others have noticed later than 6.2 and I'd suggest you actually try 6.3 to see if they are in fact an issue for you. I don't have the resources to load up the systems enough to find these problems sitting on my desk. And I can't risk production resources for problems known and reported on the *EXACT* same hardware. "oh but it won't happen to me" isn't a useful methodology in a production environment. I mean, seriously, I know the majority of you are happy rebooting your systems 5x daily to run the latest. I'll do that with my home system, no problem. But I can't do this in a production environment. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
Jo Rhett wrote: On Jun 4, 2008, at 11:39 AM, Kris Kennaway wrote: Also, it's not like anyone should have been caught by surprise by the 6.2 EoL; the expiry date has been advertised since the 6.2 release itself. It has changed multiple times. I keep reviewing and finding 6.3 bugs outstanding, and then observe the EoL get pushed. I'm surprised that it failed to get pushed this time. I'm sorry that the FreeBSD project failed to conform to your expectations. However, I invite you to actually try 6.3 for yourself instead of assuming that it will fail. Several of the bug reports have the *exact* same hardware we are using. Rackable systems with 3ware controllers. If you're asking why I don't turn a production environment over to being a freebsd-unstable-testbed, I can't really answer that question in a way you'd understand (if you were asking that question) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
Jo Rhett wrote: On Jun 4, 2008, at 12:00 PM, Scott Long wrote: Can you describe the bugs that are affecting you? gmirror failures, 3ware raid driver timeouts, bge0 problems. All three in production use on dozens of systems. Give me specific details on the 3ware and bge problems. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Wed, Jun 04, 2008 at 10:43:27AM -1000, Clifton Royston wrote: > On Wed, Jun 04, 2008 at 11:00:41AM -0700, Doug Barton wrote: > > Jo Rhett wrote: > ... > > >But given that 6.3 is still experiencing bugs with things that > > >are working fine and stable in 6.2, this is a pretty hard case to make. > > > > I admit to not having been following 6.x too closely, but are these > > things that have been reported, or problems you're having personally? > > Speaking just for myself, I'd love to get a general response from > people who have run servers on both as to whether 6.3 is on average > more stable than 6.2. I really haven't gotten any clear impression as > to this, either from posts on -hackers or -stable, and I believe I > asked a couple times. I've seen comments that 6.3 should be > considerably more stable than 6.2, but also complaints about bugs such > as Jo is commenting on, and I have not seen much committed in the way > of errata fixes for 6.3 since its release. We have about 40 servers which were running 6.1 and 6.2 and the seven busy ones (application servers which do mail and proxying, and the database servers) hung *dead* every week. One per day. Luckely they were all redundant etc and remotely rebootable, but it was a nightmare for half a year. A handfull of patches (mutex-based) helped a lot, but still it was too much for my liking. The upgrade to 6.3 fixed *everything*, these seven servers now have uptimes of (since february) again. (The updates were scheduled in November as xmas-break updates, so imagine me getting more and more nervous when things got dragged out). So 6.3 saved my sanity :-) Edwin -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://www.mavetju.org/weblog/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
Jo Rhett wrote: On Jun 4, 2008, at 11:39 AM, Kris Kennaway wrote: Also, it's not like anyone should have been caught by surprise by the 6.2 EoL; the expiry date has been advertised since the 6.2 release itself. It has changed multiple times. I keep reviewing and finding 6.3 bugs outstanding, and then observe the EoL get pushed. I'm surprised that it failed to get pushed this time. I'm sorry that the FreeBSD project failed to conform to your expectations. However, I invite you to actually try 6.3 for yourself instead of assuming that it will fail. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 4, 2008, at 4:45 PM, Edwin Groothuis wrote: We have about 40 servers which were running 6.1 and 6.2 and the seven busy ones (application servers which do mail and proxying, and the database servers) hung *dead* every week. One per day. I'm sorry to hear that. Our servers have never hung with 6.2. Reboots only occurred to satisfy kernel security patches. But with 6.3 there are many open bug reports about our exact hardware, and I'd prefer to avoid swapping positions with you ;-0 -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 4, 2008, at 12:00 PM, Scott Long wrote: Can you describe the bugs that are affecting you? gmirror failures, 3ware raid driver timeouts, bge0 problems. All three in production use on dozens of systems. This is also a fairly significant investment in terms of time and money for any business to handle this ugprade. It totally understand obsoleting 5.x now that 7.x is out. But 6.2 is barely a year old... The expectation is always that newer versions of a stable branch will have few regressions, and thus upgrading is a low risk. That's my expectation as well. The 6.3 degression has been somewhat surprising. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 4, 2008, at 11:39 AM, Kris Kennaway wrote: Also, it's not like anyone should have been caught by surprise by the 6.2 EoL; the expiry date has been advertised since the 6.2 release itself. It has changed multiple times. I keep reviewing and finding 6.3 bugs outstanding, and then observe the EoL get pushed. I'm surprised that it failed to get pushed this time. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Thu, Jun 05, 2008 at 01:21:35AM +0200, Greg Byshenk wrote: > On Wed, Jun 04, 2008 at 04:41:45PM -0500, Kevin Kinsey wrote: > > Clifton Royston wrote: > > > > For example, if I take a 6.3R CD, or build one for 6-RELENG, is there > > >a way to do an "upgrade in place" on each server? Or would it work > > >better to do a build from recent source on the development server, then > > >export /usr/src and /usr/obj via NFS to the production servers and do > > >the usual "make installkernel; reboot;" etc. sequence on them? (In my > > >case I do have all machines on one GigE switch.) > > > I've heard of the latter being done with decent results. > > I can't say that it is "better", but I do the latter (well, actually I > build on a test machine to make sure there are no problems, then sync > to an NFS server and mount src and object from there, followed by > installkernel-reboot-installworld-merge-reboot) Actually, yes, that's precisely what I was planning. I *do* at least have a separate development and test machine, apart from the main server cluster. > on a number of different > machines (currently runnign 6.3-STABLE of 2008-05-22 and 7.0-STABLE of > 2008-05-27), and it is certainly faster and easier than doing a build > on each individual machine. > > I do the same thing with ports, doing a 'portupgrade -p' on the build > machine followed by a 'portupgrade -P' on the "clients" (building > packages on the build machine, and then installing via my own packages > on the others). Again, I can't say that it is "better", but it is > certainly faster and easier. Thanks a lot for the feedback! I'll have to consider freebsd-update too; I simply haven't got used to its being available as an option. -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] / [EMAIL PROTECTED] President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Jun 4, 2008, at 11:00 AM, Doug Barton wrote: But given that 6.3 is still experiencing bugs with things that are working fine and stable in 6.2, this is a pretty hard case to make. I admit to not having been following 6.x too closely, but are these things that have been reported, or problems you're having personally? I go into the hardware and questions list and search for the hardware devices we use, and see problem reports. I see associated bugs, unclosed. I set aside upgrade for later ;-) This is also a fairly significant investment in terms of time and money for any business to handle this ugprade. Having an upgrade path is something every operation needs. "Set it and forget it" isn't a viable strategy in the current culture where 0-day vulnerabilities are becoming increasingly common. Absolutely not saying that. In fact, we had 6.3 upgrade on the books for April but when I looked in April there were still open bugs. I looked in late May and saw the same. So we punted to late June (because the original end of life was June 30th) and then suddenly we're getting messages every night saying that we're unsupported. So we're staying unsupported until 6.3 stabilizes obviously. That sucks. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Wed, Jun 04, 2008 at 04:41:45PM -0500, Kevin Kinsey wrote: > Clifton Royston wrote: > > For example, if I take a 6.3R CD, or build one for 6-RELENG, is there > >a way to do an "upgrade in place" on each server? Or would it work > >better to do a build from recent source on the development server, then > >export /usr/src and /usr/obj via NFS to the production servers and do > >the usual "make installkernel; reboot;" etc. sequence on them? (In my > >case I do have all machines on one GigE switch.) > I've heard of the latter being done with decent results. I can't say that it is "better", but I do the latter (well, actually I build on a test machine to make sure there are no problems, then sync to an NFS server and mount src and object from there, followed by installkernel-reboot-installworld-merge-reboot) on a number of different machines (currently runnign 6.3-STABLE of 2008-05-22 and 7.0-STABLE of 2008-05-27), and it is certainly faster and easier than doing a build on each individual machine. I do the same thing with ports, doing a 'portupgrade -p' on the build machine followed by a 'portupgrade -P' on the "clients" (building packages on the build machine, and then installing via my own packages on the others). Again, I can't say that it is "better", but it is certainly faster and easier. -- greg byshenk - [EMAIL PROTECTED] - Leiden, NL ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpufreq broken on core2duo
Roland Smith wrote: On Thu, Jun 05, 2008 at 08:33:24AM +1000, Andrew Snow wrote: Here's another one: CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 720072006000720 device_attach: est0 attach returned 6 p4tcc0: on cpu0 I had this on a new core2 quad. Updating to a recent 7-STABLE fixed the issue for me. Did any of you tried chkfreq which comes with acpi_ppc http://www.spa.is.uec.ac.jp/~nfukuda/software/ to check if the cpu frequency is actually changing? Thanks, Evren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpufreq broken on core2duo (was: powerd is doing nothing?)
On Thu, Jun 05, 2008 at 08:33:24AM +1000, Andrew Snow wrote: > Evren Yurtesen wrote: > > > When you say that it doesnt work, does it give an error or? In my case > > it doesnt give any errors just says it set it but I see that nothing is > > set. > > Here's one box: > > CPU: Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz > cpu0: on acpi0 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 61a49200600091a > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 > > > Here's another one: > CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz > cpu0: on acpi0 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 720072006000720 > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 I had this on a new core2 quad. Updating to a recent 7-STABLE fixed the issue for me. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpi5G9rM9GtN.pgp Description: PGP signature
Re: cpufreq broken on core2duo
Andrew Snow wrote: Evren Yurtesen wrote: When you say that it doesnt work, does it give an error or? In my case it doesnt give any errors just says it set it but I see that nothing is set. Here's one box: CPU: Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 61a49200600091a device_attach: est0 attach returned 6 p4tcc0: on cpu0 Here's another one: CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 720072006000720 device_attach: est0 attach returned 6 p4tcc0: on cpu0 SYSCTLs On the first one: dev.cpu.0.freq: 2786 dev.cpu.0.freq_levels: 2786/-1 2437/-1 2089/-1 1741/-1 1393/-1 1044/-1 696/-1 348/-1 Attempting to change dev.cpu.0.freq has no effect and says: sysctl: dev.cpu.0.freq: Invalid argument In one of the boxes I have there is an option in the bios where I can enable Intel Enhanced SpeedStep Technology. If I enable this to disabled in the bios then I get the same results as you are seeing. If I enable this in the bios then I get no errors but the processor speed doesnt change according to chkfreq from acpi_ppc http://www.spa.is.uec.ac.jp/~nfukuda/software/ Did you check the bios for this option? Another thing is that when I enable it from bios the cpufreq finds the processor to be 1500mhz (3000mhz in reality). You said you have an Athlon X2 box. Did you download http://www.spa.is.uec.ac.jp/~nfukuda/software/ and tried the chkfreq program which comes out with it to see if powerd is actually working? Because all I know is that you might be thinking that it is working but it might not be working at all. (I think acpi_ppc doesnt support dual core processors but chkfreq should give reliable results) Thanks, Evren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
cpufreq broken on core2duo (was: powerd is doing nothing?)
Evren Yurtesen wrote: When you say that it doesnt work, does it give an error or? In my case it doesnt give any errors just says it set it but I see that nothing is set. Here's one box: CPU: Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 61a49200600091a device_attach: est0 attach returned 6 p4tcc0: on cpu0 Here's another one: CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 720072006000720 device_attach: est0 attach returned 6 p4tcc0: on cpu0 SYSCTLs On the first one: dev.cpu.0.freq: 2786 dev.cpu.0.freq_levels: 2786/-1 2437/-1 2089/-1 1741/-1 1393/-1 1044/-1 696/-1 348/-1 Attempting to change dev.cpu.0.freq has no effect and says: sysctl: dev.cpu.0.freq: Invalid argument ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
7-STABLE and Intel G33
My PC has built-in intel G33 graphics, which I'm trying to get to work
in something better then vesa.
Following the instructions in
http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/039638.html
I have compiled and installed the driver and kernel modules from the git
trees for drm and the xf86-video-intel driver from today.
I also patched agp_i810.c to remove the comments from the chipset
identifiers and rebuilt the kernel.
After loading the i915.ko kernel module, and starting X with a config
file using the intel driver, I still get;
(II) intel(0): xf86BindGARTMemory: bind key 1 at 0x006ff000 (pgoffset 1791)
(WW) intel(0): xf86BindGARTMemory: binding of gart memory with key 1
at offset 0x6ff000 failed (Invalid argument)
Fatal server error:
Couldn't bind memory for front buffer
In dmesg output I see:
agp0: trying to bind into stolen memory
Looking at the Xorg.0.log, the xf86-video-intel driver and the drm and
dri drivers seem to initialize OK.
Grepping through the source, this error seems to originate in
/usr/src/sys/pci/agp_i810.c;
if ( sc->chiptype != CHIP_I810 ) {
if ( (offset >> AGP_PAGE_SHIFT) < sc->stolen ) {
device_printf(dev, "trying to bind into stolen memory");
return EINVAL;
}
[disclaimer: I'm not a software engineer by education or trade, just a
mechanical engineer who likes to tinker with computers and software]
I've been reading the agp code, the intel driver code and I've skimmed
the intel docs. I find the code quite hard to understand, and the intel
docs nigh-on unreadable.
Would modifying the if-statement to not produce this error on the
CHIP_G33 fix this problem? Or would it horribly blow up in my face?
Any help to get this to work would be very much appreciated!
Roland
--
R.F.Smith http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
pgpNuC3SyiDBc.pgp
Description: PGP signature
Crashes in devfs. Possibly on interface creation/destruction.
Hi.
After recent upgrading from 6.3-RC1/mpd-5.0rc1 to 6.3-STABLE/mpd-5.1
some of my PPPoE servers started to crash with about weekly period.
Usually they just just hang without rebooting and core dumping. Consoles
are inaccessible. All I have got from them was:
kernel: Fatal trap 12: page fau
kernel: lt while in k
kernel: ernel
kernel: mode
kernel:
kernel: cpuid = 1; apic id = 01
kernel: faut virtual address = 0x58
kernel:
kernel: fault code = supervisor read, page not present
kernel:
kernel: instruction pointer = 0x20:0xc04800be
kernel:
kernel: stack pointer= 0x28:0xd690883c
kernel: frame pointer= 0x28:0
kernel: xd6908854
kernel: code segment =
kernel: base 0x0, limit 0xf, type 0x1b
kernel:
kernel: = DPL 0, pres 1, def32 1, gra
kernel: n 1
kernel: processor eflags = interrupt
kernel: enab
kernel: led, r
kernel: esume
kernel: , IOPL
kernel: = 0
kernel:
kernel: current process = 1835 (mpd5)
kernel:
kernel: trap number = 12
"fault virtual address" and "instruction pointer" are always the same.
Address 0xc04800be looks like part of devfs code:
> addr2line -f -e kernel.debug 0xc04800be
devfs_populate_loop
/usr/src/sys/fs/devfs/devfs_devs.c:443
devfs_devs.c:
de = devfs_newdirent(s, q - s);
if (cdp->cdp_c.si_flags & SI_ALIAS) {
de->de_uid = 0;
de->de_gid = 0;
de->de_mode = 0755;
de->de_dirent->d_type = DT_LNK;
pdev = cdp->cdp_c.si_parent;
->> line 443 ->>j = strlen(pdev->si_name) + 1;
de->de_symlink = malloc(j, M_DEVFS, M_WAITOK);
bcopy(pdev->si_name, de->de_symlink, j);
0x58 - is precisely the offset of si_name field inside of struct cdev.
So looks like pdev = cdp->cdp_c.si_parent is NULL here for some reason.
As soon as network interfaces have respective devfs entries and looking
higher interface creation/destruction rate that newest mpd5.1 is able to
reach due to optimizations, I think it may be some kind or race
somewhere interface creation.
Can somebody give me any hint where to look to?
--
Alexander Motin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: powerd is doing nothing?
Andrew Snow wrote: The problem is not powerd but cpufreq. While cpufreq appears to work well on my Athlon X2, it has never worked on any of my Core2Duo or Core-based Xeon servers. This is a great shame as these newer Intel chips have the capability to clock up and down very quickly and seamlessly. Who can fix the cpufreq driver? I think it simply hasn't been updated with the latest data from Intel. Yes I can see that powerd is trying to change the frequency so agreed, cpufreq is broken. When you say that it doesnt work, does it give an error or? In my case it doesnt give any errors just says it set it but I see that nothing is set. Did you try acpi_ppc? http://www.spa.is.uec.ac.jp/~nfukuda/software/ Thanks, Evren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
Clifton Royston wrote: On Wed, Jun 04, 2008 at 11:00:41AM -0700, Doug Barton wrote: Jo Rhett wrote: ... But given that 6.3 is still experiencing bugs with things that are working fine and stable in 6.2, this is a pretty hard case to make. I admit to not having been following 6.x too closely, but are these things that have been reported, or problems you're having personally? Speaking just for myself, I'd love to get a general response from people who have run servers on both as to whether 6.3 is on average more stable than 6.2. I really haven't gotten any clear impression as to this, either from posts on -hackers or -stable, and I believe I asked a couple times. I've seen comments that 6.3 should be considerably more stable than 6.2, but also complaints about bugs such as Jo is commenting on, and I have not seen much committed in the way of errata fixes for 6.3 since its release. I'd love to pick up some more stability, but I'm feeling a little burned by 6.2 relative to 4.10, and thus twice wary. This is also a fairly significant investment in terms of time and money for any business to handle this ugprade. Having an upgrade path is something every operation needs. "Set it and forget it" isn't a viable strategy in the current culture where 0-day vulnerabilities are becoming increasingly common. Fair enough. Now I must confess my ignorance; is there a simplest straightforward way to upgrade multiple servers between releases in the same branch, other than rebuilding each from source, or wiping and reinstalling? In the past I've always done one of those two. Define "between releases"? If you have a machine running N.NR, then freebsd-update(8), maybe? Just a thought, and that not thought through, For example, if I take a 6.3R CD, or build one for 6-RELENG, is there a way to do an "upgrade in place" on each server? Or would it work better to do a build from recent source on the development server, then export /usr/src and /usr/obj via NFS to the production servers and do the usual "make installkernel; reboot;" etc. sequence on them? (In my case I do have all machines on one GigE switch.) -- Clifton I've heard of the latter being done with decent results. Kevin Kinsey -- No amount of careful planning will ever replace dumb luck. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: powerd is doing nothing?
The problem is not powerd but cpufreq. While cpufreq appears to work well on my Athlon X2, it has never worked on any of my Core2Duo or Core-based Xeon servers. This is a great shame as these newer Intel chips have the capability to clock up and down very quickly and seamlessly. Who can fix the cpufreq driver? I think it simply hasn't been updated with the latest data from Intel. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Upcoming release schedule
As some of you may know the FreeBSD Project has been attempting to shift over from "Feature based releases" to "Time based releases" as far as trying to schedule them goes. Lets just say that's still a work in progress (as in doing that with FreeBSD 7.0 didn't work out so well). This is the schedule we will be shooting for through the next several years/branches: 8/2008 7.1 and 6.4 2/2009 7.2 6/2009 8.0 8/2009 7.3 12/2009 8.1 and 7.4 3/2010 8.2 8/2010 8.3 12/2010 9.0 4/2011 9.1 and 8.4 10/2011 9.2 3/2012 9.3 6/2012 10.0 12/2012 10.1 and 9.4 No guarantees at this point, but those will be what we shoot for. I've updated the releng page on the Web site to include the first couple of those (commit was just done so it will take a little while to appear at http://www.freebsd.org/releng). -- Ken Smith - From there to here, from here to | [EMAIL PROTECTED] there, funny things are everywhere. | - Theodore Geisel | signature.asc Description: This is a digitally signed message part
powerd is doing nothing?
Hi, I have boxes with 6.2-x86 to 7.0-amd64 with CPUs from AMD and Intel ranging between Athlon64, Pentium4, Xeon processors. OK I have setup powerd and when I run powerd I see (for example): idle time > 90%, decreasing clock speed from 2978 MHz to 2605 MHz idle time > 90%, decreasing clock speed from 2605 MHz to 2233 MHz idle time > 90%, decreasing clock speed from 2233 MHz to 1861 MHz idle time > 90%, decreasing clock speed from 1861 MHz to 1489 MHz idle time > 90%, decreasing clock speed from 1489 MHz to 1116 MHz idle time > 90%, decreasing clock speed from 1116 MHz to 744 MHz idle time > 90%, decreasing clock speed from 744 MHz to 372 MHz and sysctl's seem to be in order: dev.cpu.0.freq: 372 dev.cpu.0.freq_levels: 2978/-1 2605/-1 2233/-1 1861/-1 1489/-1 1116/-1 744/-1 372/-1 dev.p4tcc.0.freq_settings: 1/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 However, I downloaded acpi_ppc from http://www.spa.is.uec.ac.jp/~nfukuda/software/ and there comes a program called chkfreq with it which measures the cpu time. It always shows the maximum speed. For example 2992751205 for 3ghz P4 (from the above examples) regardless of what freq is set. OK lets say the chkfreq is faulty, but I tested this on another machine with 6.2 box with: CPU: AMD Athlon(tm) 64 Processor 3500+ (2202.83-MHz 686-class CPU) and acpi_ppc says: cpu0: Px state: P0, 2200MHz, 89000mW, 100us, 7us cpu0: Px state: P1, 2000MHz, 69000mW, 100us, 7us cpu0: Px state: P2, 1800MHz, 5mW, 100us, 7us cpu0: Px state: P3, 1000MHz, 22000mW, 100us, 7us cpu0: Px method: AMD K8 Cool'n'Quiet and when at 1000mhz chkfreq shows 1001297861 when I unload acpi_ppc it shows 2202845489. Then I load cpufreq and I see: powernow0: on cpu0 and run powerd dev.cpu.0.freq: 1000 dev.cpu.0.freq_levels: 2200/89000 2000/69000 1800/5 1000/22000 dev.powernow.0.freq_settings: 2200/89000 2000/69000 1800/5 1000/22000 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 but when I run chkfreq I get 2202846202 (I checked with -v, powerd does not increase speed while testing) I tested powerd on several machines with p4, athlon64, xeon processors and it seems to work in none of the machines properly. Does anybody know how any way to check for sure if powerd is really working or not? Thanks, Evren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
On Wed, Jun 04, 2008 at 11:00:41AM -0700, Doug Barton wrote: > Jo Rhett wrote: ... > >But given that 6.3 is still experiencing bugs with things that > >are working fine and stable in 6.2, this is a pretty hard case to make. > > I admit to not having been following 6.x too closely, but are these > things that have been reported, or problems you're having personally? Speaking just for myself, I'd love to get a general response from people who have run servers on both as to whether 6.3 is on average more stable than 6.2. I really haven't gotten any clear impression as to this, either from posts on -hackers or -stable, and I believe I asked a couple times. I've seen comments that 6.3 should be considerably more stable than 6.2, but also complaints about bugs such as Jo is commenting on, and I have not seen much committed in the way of errata fixes for 6.3 since its release. I'd love to pick up some more stability, but I'm feeling a little burned by 6.2 relative to 4.10, and thus twice wary. > >This is also a fairly significant investment in terms of time and money > >for any business to handle this ugprade. > > Having an upgrade path is something every operation needs. "Set it and > forget it" isn't a viable strategy in the current culture where 0-day > vulnerabilities are becoming increasingly common. Fair enough. Now I must confess my ignorance; is there a simplest straightforward way to upgrade multiple servers between releases in the same branch, other than rebuilding each from source, or wiping and reinstalling? In the past I've always done one of those two. For example, if I take a 6.3R CD, or build one for 6-RELENG, is there a way to do an "upgrade in place" on each server? Or would it work better to do a build from recent source on the development server, then export /usr/src and /usr/obj via NFS to the production servers and do the usual "make installkernel; reboot;" etc. sequence on them? (In my case I do have all machines on one GigE switch.) -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] / [EMAIL PROTECTED] President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
Stephen Clark wrote: Scott Long wrote: Jo Rhett wrote: Okay, I totally understand that FreeBSD wants people to upgrade from 6.2 to 6.3. But given that 6.3 is still experiencing bugs with things that are working fine and stable in 6.2, this is a pretty hard case to make. Can you describe the bugs that are affecting you? This is also a fairly significant investment in terms of time and money for any business to handle this ugprade. It totally understand obsoleting 5.x now that 7.x is out. But 6.2 is barely a year old... The expectation is always that newer versions of a stable branch will have few regressions, and thus upgrading is a low risk. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" Can just the kernel be upgraded or does all of user space have to be upgrades to. Most things will work fine with slightly mismatched kernels, but it's not recommended to do this (some utilities may not work properly). How would someone recommend upgrading 500 hundred remote sites spread throughout Thoroughly test on identically configured machines, roll out incrementally and make sure you have a fallback (i.e. console access) in case something goes catastrophically wrong. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
Scott Long wrote: Jo Rhett wrote: Okay, I totally understand that FreeBSD wants people to upgrade from 6.2 to 6.3. But given that 6.3 is still experiencing bugs with things that are working fine and stable in 6.2, this is a pretty hard case to make. Can you describe the bugs that are affecting you? This is also a fairly significant investment in terms of time and money for any business to handle this ugprade. It totally understand obsoleting 5.x now that 7.x is out. But 6.2 is barely a year old... The expectation is always that newer versions of a stable branch will have few regressions, and thus upgrading is a low risk. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" Can just the kernel be upgraded or does all of user space have to be upgrades to. How would someone recommend upgrading 500 hundred remote sites spread throughout the US? Thanks, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lenovo Thinkpad t61p and FreeBSD?
On Wed, 2008-06-04 at 07:45 -0500, Josh Paetzel wrote: > On Wednesday 04 June 2008 07:25:13 am Jeremy Chadwick wrote: > > On Tue, Jun 03, 2008 at 11:13:27AM -0400, [EMAIL PROTECTED] wrote: > > > Quoting [EMAIL PROTECTED]: > > > > Quoting Jeremy Chadwick <[EMAIL PROTECTED]>: > > > > > Based on my experiences with my workplace-provided T60p, it's safe to > > > > > say I'll never recommend a Lenovo product. The temperatures of these > > > > > laptops are absolutely insane, supported by an incredibly loud fan. > > > > > I'm not interested in a product that can have a GPU reaching > > > > > temperatures of almost 70C **while idling**. > > > > > > > > I purchased a T60p about two months ago and I haven't had any of these > > > > happen (yet?) running Ubuntu 7.10. The machine only gets slightly warm > > > > to the touch after a few hours idling. > > > > > > > > Does your fan run all the time that loud? I'm wondering if there were > > > > changes made at the factory to fix this type of problem if it was wide > > > > spread. > > > > > > > > Regards, > > > > Nick LaRoche > > > > > > That was a T61p not a T60p > > > > It really doesn't matter in this case; T60p, T60p (widescreen), T61p, > > X60p, etc... They all behave the same way when it comes to > > temperatures: incredibly high, sometimes to the point of the system > > shutting off (for some). > > My T60p is really unusable for anything cpu intensive under FreeBSD. Even > with the ibm acpi addons loaded and the fan set to it's highest setting it > only turns at 3700rpm, which isn't enough to keep it from shutting down due > to heat. (eg over 100C) > > I'm interested in whatever cooling solutions people have... > You can read through this thread: http://www.freebsd.org/cgi/getmsg.cgi?fetch=141019+0 +/usr/local/www/db/text/2008/freebsd-acpi/20080217.freebsd-acpi which mentions at least two ways to approach it -- the right one from the referenced message forward. HTH, -- Alexandre "Sunny" Kovalenko (Олександр Коваленко) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
Jo Rhett wrote: Okay, I totally understand that FreeBSD wants people to upgrade from 6.2 to 6.3. But given that 6.3 is still experiencing bugs with things that are working fine and stable in 6.2, this is a pretty hard case to make. Can you describe the bugs that are affecting you? This is also a fairly significant investment in terms of time and money for any business to handle this ugprade. It totally understand obsoleting 5.x now that 7.x is out. But 6.2 is barely a year old... The expectation is always that newer versions of a stable branch will have few regressions, and thus upgrading is a low risk. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
Doug Barton wrote: Jo Rhett wrote: Okay, I totally understand that FreeBSD wants people to upgrade from 6.2 to 6.3. It isn't that we want people to upgrade, it's that we are trying to be realistic regarding what we have the resources to support. But given that 6.3 is still experiencing bugs with things that are working fine and stable in 6.2, this is a pretty hard case to make. I admit to not having been following 6.x too closely, but are these things that have been reported, or problems you're having personally? This is also a fairly significant investment in terms of time and money for any business to handle this ugprade. Having an upgrade path is something every operation needs. "Set it and forget it" isn't a viable strategy in the current culture where 0-day vulnerabilities are becoming increasingly common. Also, it's not like anyone should have been caught by surprise by the 6.2 EoL; the expiry date has been advertised since the 6.2 release itself. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Why does sysinstall still limits cylinders to 65535?
On Tuesday 03 June 2008 10:49:41 pm Doug Barton wrote: > Carlos A. M. dos Santos wrote: > > On Mon, May 26, 2008 at 3:24 AM, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > >> On Sun, May 25, 2008 at 11:52:06PM -0300, Carlos A. M. dos Santos wrote: > >>> I have been struglling with sysinstall, attempting to make it handle > >>> the geometry of some large SATA drives. After a lot of effort I > >>> decided to stop suffering and modified the program in order to > >>> circumvent the outdated limit of 65535 cylinders (see attached patch). > >>> I'm thinking about submitting a PR with a change request but I'd like > >>> to get some additional opinions first. I did not test it in "batch" > >>> mode, so it would be great if any kind soul did this. > >> Carlos, bottom line is to simply ignore the geometry warning you see. > >> > >> For others... > >> > >> This is just added evidence that the humongous warning spit out during > >> sysinstall's fdisk is confusing users (many taking it very seriously > >> when there's really no problem at all). > >> > >> I think this is the third time someone's brought this up in the past > >> couple months... > > > > Sorry if I sound annoying but nobody else answered. I still believe > > that something must be done to fix sysinstall, so I'm asking you > > (where "you" means the "others" in Jeremy's message) to provide some > > additional feedback. Please fill-in the dots in one or more of the > > following options: > > > > 1. We can not make such change sysinstall because ... > > > > 2. Your patch is not correct/sufficient. I would be better if ... > > > > 3. Please submit a PR. It will momentarily be reviewed by ... > > > > 4. Give up. Nobody here cares about this issue. > > 5. -stable is not the right list to discuss sysinstall issues. > freebsd-hackers would be the first choice, if you don't get a response > there, -current would be the next. > > Send the PR first, and in your message give a brief background of your > issue and a URL for the PR. That way when it gets reviewed the feedback > will be consolidated into one convenient location. > > If you want "momentary" review for your work, open source is probably > not the arena you should be looking to contribute in. 6. The Real Fix(tm) would be to change sysinstall to allow use of GPT partitions (GPT doesn't use C/H/S at all, so the warning would only be present for the MBR/BSD label case) and then enable those by default. You would still need to allow for MBR/BSD layouts for some embedded devices that don't support the BIOS EDD packet mode (i.e. doing disk I/O using LBA's rather than C/H/S). -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Interrupt storm with shared interrupt on digi(4)
On Tuesday 03 June 2008 03:04:18 pm Peter Jeremy wrote: > BTW, your MUA's list-reply configuration don't recognize that > freebsd-stable@ and stable@ are aliases. Yes, kmail is broken and the authors refuse to fix it. It happens on reply to a foo@ e-mail (it changes the 'To' to 'freebsd-foo@' because of the List-Id header and leaves foo@ in the 'CC' field). Note that there isn't anything in the List headers that says that foo@ is an alias for [EMAIL PROTECTED] I just wish I could turn off the List-Id crap and use plain old reply-to-all, but that is where the kmail developers disagree. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: challenge: end of life for 6.2 is premature with buggy 6.3
Jo Rhett wrote: Okay, I totally understand that FreeBSD wants people to upgrade from 6.2 to 6.3. It isn't that we want people to upgrade, it's that we are trying to be realistic regarding what we have the resources to support. But given that 6.3 is still experiencing bugs with things that are working fine and stable in 6.2, this is a pretty hard case to make. I admit to not having been following 6.x too closely, but are these things that have been reported, or problems you're having personally? This is also a fairly significant investment in terms of time and money for any business to handle this ugprade. Having an upgrade path is something every operation needs. "Set it and forget it" isn't a viable strategy in the current culture where 0-day vulnerabilities are becoming increasingly common. hth, Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
challenge: end of life for 6.2 is premature with buggy 6.3
Okay, I totally understand that FreeBSD wants people to upgrade from 6.2 to 6.3. But given that 6.3 is still experiencing bugs with things that are working fine and stable in 6.2, this is a pretty hard case to make. This is also a fairly significant investment in terms of time and money for any business to handle this ugprade. It totally understand obsoleting 5.x now that 7.x is out. But 6.2 is barely a year old... -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lenovo Thinkpad t61p and FreeBSD?
Richard Arends wrote: On Wed, Jun 04, 2008 at 07:45:12AM -0500, Josh Paetzel wrote: Hi, I'm interested in whatever cooling solutions people have... I didn't follow this thread earlier because I don't have this laptop, but I wonder if anyone has offered the suggestion to blow out all the vents and heatsinks with compressed air yet? Even in a fairly "healthy" environment at home my laptop gets a non-trivial amount of dust buildup. I blow it clean about once a month and get visible results each time. hth, Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mystery: lock up after fs dump
On Wed, Jun 04, 2008 at 06:33:45PM +0300, Andriy Gapon wrote: > on 04/06/2008 18:23 Kostik Belousov said the following: > > On Wed, Jun 04, 2008 at 06:07:47PM +0300, Andriy Gapon wrote: > [snip] > >> dumps are done on live filesystems using -L. > [snip] > >> 4. both systems have gjournal support (on 6.X it is added via a > >> "non-official" patch), there are gjournaled filesystems on both systems > >> and they are dumped. > > > > Do you use snapshots on the gjournaled fs ? I believe this is problematic. > > Yes, I do via dump -L. I don't otherwise (no mksnap_ffs). > I had some thoughts about that. > But... I remember discussing this on geom list and I think pjd said that > this should work and also it worked for me flawlessly except for that > one moment. > BTW, those filesystems are mounted like the following: > ufs, asynchronous, local, noatime, gjournal > This is to say that I do not mix gjournal and softupdates, which is also > possible (at least not prohibited). SU are irrelevant to the problem I am thinking of. vfs_write_suspend() returns 0 when the filesystem being suspended is already in suspend state. vfs_write_resume() clears the suspend state. vfs_write_suspend/vfs_write_resume are used both by snapshot code and the gjournal. If two users of these interfaces interleave, then you could get: thread1 thread2 vfs_write_suspend() <- fs is suspended there vfs_write_suspend() <- returns 0 vfs_write_resume() <- fs is no more suspended thread2 is burned in flame Snapshots are protected against this because they are created through the mount(2). The mount(2) locks the covered vnode and thus serializes snapshot creation (I think there are further serialization points that prevent simultaneous snapshotting of the same fs). There is nothing I can see that protects snapshots/gjournal interaction. pgpOaEHFrzUnG.pgp Description: PGP signature
Re: mystery: lock up after fs dump
On Wed, Jun 04, 2008 at 06:33:45PM +0300, Andriy Gapon wrote: > on 04/06/2008 18:23 Kostik Belousov said the following: > > On Wed, Jun 04, 2008 at 06:07:47PM +0300, Andriy Gapon wrote: > [snip] > >> dumps are done on live filesystems using -L. > [snip] > >> 4. both systems have gjournal support (on 6.X it is added via a > >> "non-official" patch), there are gjournaled filesystems on both systems > >> and they are dumped. > > > > Do you use snapshots on the gjournaled fs ? I believe this is problematic. > > Yes, I do via dump -L. I don't otherwise (no mksnap_ffs). > I had some thoughts about that. > But... I remember discussing this on geom list and I think pjd said that > this should work and also it worked for me flawlessly except for that > one moment. > BTW, those filesystems are mounted like the following: > ufs, asynchronous, local, noatime, gjournal > This is to say that I do not mix gjournal and softupdates, which is also > possible (at least not prohibited). I haven't seen hard system lock-ups when using dump (the -L on UFS2 systems is implied, but you're not using softupdates, so maybe it's not implied on such), but I have seen all I/O on the system lock up hard until the actual snapshot finishes being taken. I mentioned this a while ago on -stable (not sure; I can dig up the thread), and was told that essentially this is a known problem with snapshots on UFS2, and that the problem over time gets worse and worse. Ultimately I stopped using dump and switched to rsync. -- | 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: mystery: lock up after fs dump
on 04/06/2008 18:23 Kostik Belousov said the following: > On Wed, Jun 04, 2008 at 06:07:47PM +0300, Andriy Gapon wrote: [snip] >> dumps are done on live filesystems using -L. [snip] >> 4. both systems have gjournal support (on 6.X it is added via a >> "non-official" patch), there are gjournaled filesystems on both systems >> and they are dumped. > > Do you use snapshots on the gjournaled fs ? I believe this is problematic. Yes, I do via dump -L. I don't otherwise (no mksnap_ffs). I had some thoughts about that. But... I remember discussing this on geom list and I think pjd said that this should work and also it worked for me flawlessly except for that one moment. BTW, those filesystems are mounted like the following: ufs, asynchronous, local, noatime, gjournal This is to say that I do not mix gjournal and softupdates, which is also possible (at least not prohibited). -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mystery: lock up after fs dump
On Wed, Jun 04, 2008 at 06:07:47PM +0300, Andriy Gapon wrote: > > I wouldn't report this if not for one coincidence (which is described > below). I have too little facts, so this is more of a mystery problem > tale than a real problem report. > > There are two systems: > 1. old, slow, i386, UP, 7-STABLE > 2. new, fast, amd64, MP, 6.3-RELEASE > > Systems are located at different physical locations. > > What is common between them: > 1. they both have the same backup strategy where dumps of certain levels > are performed on certain days; there are monthly dumps of level 2 (on > first day of each month), weekly dumps of level 4 (each Sunday) and > daily dumps of levels > 5 (each day except for Sunday - but including > the firsts). > dumps are done on live filesystems using -L. > dumps are initially done to the same disk and only later are transfered > to archive media. > 2. both kernels are compiled with softupdates support but there are no > filesystems with it enabled > 3. both systems have root partition gmirror-ed, it is dumped > 4. both systems have gjournal support (on 6.X it is added via a > "non-official" patch), there are gjournaled filesystems on both systems > and they are dumped. > > On June 1 (Sunday) exactly the same thing happened on both systems. > At 4AM monthly level 2 dump was started and successfully performed. > At 5AM weekly level 4 dump was started. > Somewhere in the process of it system locked up. > When I physically accessed the systems I found the following: keyboard > didn't respond[*], screen froze, no pings. After reset I found that logs > stopped being updated at some timer shortly after 5AM. > [*] - although on amd64 system I was able to switch exactly once between > virtual terminals (actually from X terminal to console terminal). But > that's all, no led responses, no special combinations (like break to > debugger - it is compiled in / enabled). > > This coincidence in details (and that one successful VT switch) lead me > to believe that this was some lock up in kernel rather than a hardware > problem. Also, I use that backup scheme for almost a year and never had > such a problem before. I just checked and this was the first time that > the 1st of a month fell on Sunday, so this was the first time when level > 2 dump was followed by level 4 dump. In previous months it was followed > by level > 6 dumps. > > All in all, quite strange. Do you use snapshots on the gjournaled fs ? I believe this is problematic. pgpD0v2fTTdNN.pgp Description: PGP signature
mystery: lock up after fs dump
I wouldn't report this if not for one coincidence (which is described below). I have too little facts, so this is more of a mystery problem tale than a real problem report. There are two systems: 1. old, slow, i386, UP, 7-STABLE 2. new, fast, amd64, MP, 6.3-RELEASE Systems are located at different physical locations. What is common between them: 1. they both have the same backup strategy where dumps of certain levels are performed on certain days; there are monthly dumps of level 2 (on first day of each month), weekly dumps of level 4 (each Sunday) and daily dumps of levels > 5 (each day except for Sunday - but including the firsts). dumps are done on live filesystems using -L. dumps are initially done to the same disk and only later are transfered to archive media. 2. both kernels are compiled with softupdates support but there are no filesystems with it enabled 3. both systems have root partition gmirror-ed, it is dumped 4. both systems have gjournal support (on 6.X it is added via a "non-official" patch), there are gjournaled filesystems on both systems and they are dumped. On June 1 (Sunday) exactly the same thing happened on both systems. At 4AM monthly level 2 dump was started and successfully performed. At 5AM weekly level 4 dump was started. Somewhere in the process of it system locked up. When I physically accessed the systems I found the following: keyboard didn't respond[*], screen froze, no pings. After reset I found that logs stopped being updated at some timer shortly after 5AM. [*] - although on amd64 system I was able to switch exactly once between virtual terminals (actually from X terminal to console terminal). But that's all, no led responses, no special combinations (like break to debugger - it is compiled in / enabled). This coincidence in details (and that one successful VT switch) lead me to believe that this was some lock up in kernel rather than a hardware problem. Also, I use that backup scheme for almost a year and never had such a problem before. I just checked and this was the first time that the 1st of a month fell on Sunday, so this was the first time when level 2 dump was followed by level 4 dump. In previous months it was followed by level > 6 dumps. All in all, quite strange. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lenovo Thinkpad t61p and FreeBSD?
On Wed, Jun 04, 2008 at 07:45:12AM -0500, Josh Paetzel wrote: Hi, > I'm interested in whatever cooling solutions people have... For my T60 i made a perl script for controlling the fans and the cpu speed. A few months ago i changed it to work together with powerd and i must say, i got it pretty workable now. With a normal workload (browsing the internet, reading mail, ssh'ing to control the rest of the world), the temp is under 60 degrees. http://www.unixguru.nl/made/ibm_fancontrol_fbsd.txt -- Regards, Richard. /* Homo Sapiens non urinat in ventum */ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lenovo Thinkpad t61p and FreeBSD?
On Wednesday 04 June 2008 07:25:13 am Jeremy Chadwick wrote: > On Tue, Jun 03, 2008 at 11:13:27AM -0400, [EMAIL PROTECTED] wrote: > > Quoting [EMAIL PROTECTED]: > > > Quoting Jeremy Chadwick <[EMAIL PROTECTED]>: > > > > Based on my experiences with my workplace-provided T60p, it's safe to > > > > say I'll never recommend a Lenovo product. The temperatures of these > > > > laptops are absolutely insane, supported by an incredibly loud fan. > > > > I'm not interested in a product that can have a GPU reaching > > > > temperatures of almost 70C **while idling**. > > > > > > I purchased a T60p about two months ago and I haven't had any of these > > > happen (yet?) running Ubuntu 7.10. The machine only gets slightly warm > > > to the touch after a few hours idling. > > > > > > Does your fan run all the time that loud? I'm wondering if there were > > > changes made at the factory to fix this type of problem if it was wide > > > spread. > > > > > > Regards, > > > Nick LaRoche > > > > That was a T61p not a T60p > > It really doesn't matter in this case; T60p, T60p (widescreen), T61p, > X60p, etc... They all behave the same way when it comes to > temperatures: incredibly high, sometimes to the point of the system > shutting off (for some). My T60p is really unusable for anything cpu intensive under FreeBSD. Even with the ibm acpi addons loaded and the fan set to it's highest setting it only turns at 3700rpm, which isn't enough to keep it from shutting down due to heat. (eg over 100C) I'm interested in whatever cooling solutions people have... -- Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB signature.asc Description: This is a digitally signed message part.
Re: Lenovo Thinkpad t61p and FreeBSD?
On Tue, Jun 03, 2008 at 11:12:41AM -0400, [EMAIL PROTECTED] wrote:
> Quoting Jeremy Chadwick <[EMAIL PROTECTED]>:
> > Based on my experiences with my workplace-provided T60p, it's safe to
> > say I'll never recommend a Lenovo product. The temperatures of these
> > laptops are absolutely insane, supported by an incredibly loud fan. I'm
> > not interested in a product that can have a GPU reaching temperatures of
> > almost 70C **while idling**.
>
> I purchased a T60p about two months ago and I haven't had any of these happen
> (yet?) running Ubuntu 7.10. The machine only gets slightly warm to the touch
> after a few hours idling.
I pointed out earlier in the thread that Linux appears to have full ACPI
support for the Thinkpad series, including extras -- which probably
manage some of the thermal-related features better.
> Does your fan run all the time that loud?
Within 10-15 seconds of logging in (to Vista), the fan kicks on medium
speed. As we all know, Vista enjoys chewing CPU and disk prior to and
after logging in, and takes about 5 minutes to relax (assuming you
disable Indexing, ReadyBoost, and SuperFetch). After about 10-15
minutes, the fan usually kicks into high mode, and remains that way
until the laptop has a chance to go into sleep/power save mode -- or, if
the rear of the laptop is raised up off the desk. The amount of hot air
coming out of the fan slot on the left side is fairly substantial,
indicating the overall design of the laptop is bad, thermal-wise.
A couple of my co-workers (but only a few!) do not have this problem.
Their laptops run with the fan off, or in low mode. When we were all
using XP, I had them run the Thinkpad monitoring utility (an open-source
app) to look at the thermals of all the different parts in the system.
Their temps were substantially lower than mine (particularly the GPU),
but in others, were higher.
This could indicate a problem similar to Apple and their Macbooks, where
assembly line folks were applying entire tubes of thermal compound to
the CPU heatsink area. I haven't taken the time to open one of the
Lenovo laptops up -- company rules don't permit me to do so, and I don't
trust the coherency of our IT department anyways. ("Sounds isolated,
better just replace the entire laptop" "Umm, no...")
There are other problems with these laptops, not just thermal-related.
The laptop emits high-pitch noises as a result of some power-saving
modes the Centrino Duo chipset has. They've been documented in full on
the RMClock forum, and there are workarounds using either RMClock or (my
preferred method) turning off two options in the BIOS. If you can't
hear the noise, then your hearing isn't as sensitive as some peoples. I
can dig up the exact BIOS labels if you'd like them.
> I'm wondering if there were changes made at the factory to fix this
> type of problem if it was wide spread.
Possibly. There's quite a lot of evidence on the Web about this problem
with Lenovo laptops. IBM/Lenovo's T43 series did not behave this way,
but they were on older (cooler, temperature-wise) hardware.
--
| 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: Lenovo Thinkpad t61p and FreeBSD?
Quoting Jeremy Chadwick <[EMAIL PROTECTED]>: > Based on my experiences with my workplace-provided T60p, it's safe to > say I'll never recommend a Lenovo product. The temperatures of these > laptops are absolutely insane, supported by an incredibly loud fan. I'm > not interested in a product that can have a GPU reaching temperatures of > almost 70C **while idling**. I purchased a T60p about two months ago and I haven't had any of these happen (yet?) running Ubuntu 7.10. The machine only gets slightly warm to the touch after a few hours idling. Does your fan run all the time that loud? I'm wondering if there were changes made at the factory to fix this type of problem if it was wide spread. Regards, Nick LaRoche ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lenovo Thinkpad t61p and FreeBSD?
On Tue, Jun 03, 2008 at 11:13:27AM -0400, [EMAIL PROTECTED] wrote: > Quoting [EMAIL PROTECTED]: > > Quoting Jeremy Chadwick <[EMAIL PROTECTED]>: > > > Based on my experiences with my workplace-provided T60p, it's safe to > > > say I'll never recommend a Lenovo product. The temperatures of these > > > laptops are absolutely insane, supported by an incredibly loud fan. I'm > > > not interested in a product that can have a GPU reaching temperatures of > > > almost 70C **while idling**. > > > > I purchased a T60p about two months ago and I haven't had any of these > > happen > > (yet?) running Ubuntu 7.10. The machine only gets slightly warm to the touch > > after a few hours idling. > > > > Does your fan run all the time that loud? I'm wondering if there were > > changes > > made at the factory to fix this type of problem if it was wide spread. > > > > Regards, > > Nick LaRoche > > That was a T61p not a T60p It really doesn't matter in this case; T60p, T60p (widescreen), T61p, X60p, etc... They all behave the same way when it comes to temperatures: incredibly high, sometimes to the point of the system shutting off (for some). -- | 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: Lenovo Thinkpad t61p and FreeBSD?
Quoting [EMAIL PROTECTED]: > Quoting Jeremy Chadwick <[EMAIL PROTECTED]>: > > Based on my experiences with my workplace-provided T60p, it's safe to > > say I'll never recommend a Lenovo product. The temperatures of these > > laptops are absolutely insane, supported by an incredibly loud fan. I'm > > not interested in a product that can have a GPU reaching temperatures of > > almost 70C **while idling**. > > I purchased a T60p about two months ago and I haven't had any of these happen > (yet?) running Ubuntu 7.10. The machine only gets slightly warm to the touch > after a few hours idling. > > Does your fan run all the time that loud? I'm wondering if there were changes > made at the factory to fix this type of problem if it was wide spread. > > Regards, > Nick LaRoche > > That was a T61p not a T60p ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
