Re: kernel panic on em0/taskq
On Sat, Jun 7, 2008 at 2:34 PM, Daniel Ponticello [EMAIL PROTECTED] wrote: Hello, i'm experiencing periodic kernel panics on a server with FreeBSD 7.0-STABLE #0: Tue May 20 19:09:43 CEST 2008. My big problem is that the system is not performing memory dumping and/or automatic reoboot, it just stays there. Here' console output: em0: watchdog timeout -- resetting kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic_id = 00 fault virtual address = 0x14 fault code = supervisor read, page not present intruction pointerr = 0x20:0xc056e2ce stack pointer = 0x28:0xe537fc08 frame pointer= 0x28:0xe537fc28 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 29 (em0 taskq) trap number = 12 panic: page fault cpuid = 0 It just stays there, unresponsive (no automatic reboot). Any ideas? There was a problem in the watchdog path, I don't recall if it was checked in to STABLE, I will check after the weekend. But, there is also the question of why you are in the watchdog path in the first place. Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On 6/7/08, Jo Rhett [EMAIL PROTECTED] wrote: The question I raised is simply: given the number of bugs opened and fixed since 6.3-RELEASE shipped, why is 6.3 the only supported version? Why does it make sense for FreeBSD to stop supporting a stable version and force people to choose between two different unstable versions? Is this really the right thing to do? Define the terms stable and unstable, how you measure said stability and instability, and what you are comparing them against. Only then can people understand what you are talking about, and can any kind of meaningful dialog occur. Right now, you are saying one thing, people are hearing another, and responding with something else. Oh, and be sure to back things up with actual data, otherwise there's no point in going any further with this. -- Freddie Cash [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: gmirror patches
Hi, Has anybody else had a chance to try the gmirror patches I posted here a few weeks ago ? http://www.freebsd.org/cgi/query-pr.cgi?pr=123630 I ran that patch against 7-stable, build flawless. I currently build a kernel, by accident I made a small mistake. I installworld'd but forgot to rebuild/install the kernel, a reboot in between... oh well. That box does collect syslog of abount 8 boxes, mysql in replication modus for backup purposes to a NFS share and is internal fallback mx server so it's somewhat I/O bound. It's a HP LH3 SMP box deployed with gmirror because it lacks scsi raid. So far it runs okay. Any hints I should look for or put into stress ? It's not very important to get this box up ;-) Cheers, Robert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic on em0/taskq
Hello Jack! There was a problem in the watchdog path, I don't recall if it was checked in to STABLE, I will check after the weekend. But, there is also the question of why you are in the watchdog path in the first place. I tried to apply the latest patch 1.184.2.3 2008/05/21 21:34:05 which includes the watchdog fix you mentioned. Let's see if it helps! No idea of why i'm in the watchdog path, but I forgot to add that this is virtualized VM on VmWare ESX (it emulates em interface)... so i guess it might the cause of why i am in the watchdog path. Do you have any ideas of why i wasn't able to collect dump and the system did not reboot automatically? Thanks, Daniel -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2; 6.3; EOL; combustible discussions
On Sun, 8 Jun 2008 10:17:20 +0800 Adrian Chadd [EMAIL PROTECTED] wrote: and users should be happy that there's even a project here they can get access to without some kind of warez-like upload/download ratio. Although I agree that FreeBSD's availability to the public is great I do not agree with this you are a user, so just be happy attitude. If developers get pissed off by (some) user comments I might understand that, but if they can't deal with users and their POVs they might better quit being a developer to an -open- project like FreeBSD and start developing products just for themselves. You have developers in 'flavours'; you also have all sorts of users ;-) further discussion is just going to upset people even further. :) Being/geeting upset is -always- ones own fault. After all, it's only a discussion, not a war. So why be upset about words? -- Dick Hoogendijk -- PGP/GnuPG key: 01D2433D ++ http://nagual.nl/ + SunOS sxde 01/08 ++ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
console access
--On June 7, 2008 2:16:26 PM -0700 Jo Rhett jrhett at netconsonance.com wrote: On Jun 5, 2008, at 11:35 AM, Paul Schmehl wrote: It's not quite that simple. To do that, I have to block out time to drive 45 miles during my supposed off hours and do the upgrade there. Because, if it breaks networking and I'm at home, the server will be down for at least an hour until I can drive to the hosting company, get access to the server and restore the old kernel. Paul, you should arrange with your colocation provider to get an out of band serial connection to the system, and configure the console to go to the serial port. We provide that for free at $EMPLOYER and most other places I know of do it for free or nominal charge. or if your colocation provider is using any modern server hardware (HP, Dell, IBM) and I bet they do, they should give you lights-out access (HP's ILO2, Dell's DRAC). Then you can even remotely mount iso images from your laptop at home directly on the server (very handy sometimes). -- Andy Kosela ora et labora ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: console access
Andy Kosela wrote: Then you can even remotely mount iso images from your laptop at home directly on the server (very handy sometimes). Incidentally, when I tried to use a Supermicro IPMI card for networked remote media, FreeBSD boot loader crashed the machine (video went haywire and it didnt boot). The same thing happened when trying to use a USB CDROM drive, so I suspect USB boot support is at fault somehow. - Andrew ___ 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
Hello, On Sat, Jun 07, 2008 at 03:11:42PM -0700, Jo Rhett wrote: On Jun 7, 2008, at 1:44 PM, Patrick M. Hausen wrote: Upgrading your systems to 6.3 takes _precisely_ the same amount of work as upgrading to 6-STABLE as of today 00:00 GMT. No, it doesn't. You can get to 6.3 with freebsd-update. And you can stay patched with freebsd-update on a -RELEASE. For a corporation to choose to stick with -RELEASE makes perfect sense, and it specifically what the -RELEASE versions were intended for. Correct, that's why we are running RELENG_6_3 on ~40 machines. People who have issues with RELENG_6_3 should upgrade to RELENG_6 which is perfectly supported. I'm sorry, but you clearly don't run RELENG_6 on anything. I run it on two home computers, and grabbing it on any given day and trying to run with it in production is insanity. That's not true. I'm running FreeBSD since 1994 and I've run RELENG_N in production at various stages including N = 3, 4, 5 and 6. Lots and lots of things are committed, reverted, recommitted, reverted and then finally redesigned. Each of those steps are often committed to the source tree. Big changes that affect various parts of the system are announced by HEADS UP messages on the -stable mainling list. And by naming today 00:00 I did not mean to suggest an _arbitrary_ state of the source tree but one you are to _pick_ based on commits and mailing list information. For example, when Jack comitted his fixes for em(4), we set the checkout date to just past he did precisely that. cvsup, make world, reboot, test (!), rollout ... I have never ever had a single problem caused by running RELENG_N. We changed that only because as the number of machines increases it pays to run the same software on all of them, and RELEASE provides a convenient (!) reference point for that. Yet, if I were affected by a particular bug in RELENG_6_3, I would simply pick my own later reference point at which the bug is fixed. Kind regards, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 [EMAIL PROTECTED] http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ 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: Patrick M. Hausen [EMAIL PROTECTED] I have never ever had a single problem caused by running RELENG_N. We changed that only because as the number of machines increases it pays to run the same software on all of them, and RELEASE provides a convenient (!) reference point for that. Yet, if I were affected by a particular bug in RELENG_6_3, I would simply pick my own later reference point at which the bug is fixed. An alternative to this is to maintain a specific set of patches to -RELEASE for only the issues / fixes that you are experiencing. This has worked very well for us over the years so I can recommend it as well. Either way you get stable release which you can test and certify in your own environment, keeping regression risks to an absolute minimum. 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 Sat, Jun 07, 2008 at 03:11:42PM -0700, Jo Rhett wrote: On Jun 7, 2008, at 1:44 PM, Patrick M. Hausen wrote: This is why EoLing 6.2 and forcing people to upgrade to a release with lots of known issues is a problem. People who have issues with RELENG_6_3 should upgrade to RELENG_6 which is perfectly supported. I'm sorry, but you clearly don't run RELENG_6 on anything. I run it on two home computers, and grabbing it on any given day and trying to run with it in production is insanity. Lots and lots of things are committed, reverted, recommitted, reverted and then finally redesigned. Each of those steps are often committed to the source tree. The -RELEASE versions prevent this kind of insanity. I can't speak for Patrick, but I can ad that I very definitely _do_ run RELENG_6 on ~40 machines (web, mail, file, and applications servers), and do so without any serious problems. Which is not to say that there are never problems, but that when there have been problems, they have been uncovered during testing. Of course it is true that grabbing something and trying to run with it in production is insanity. But this (at least IMO) has nothing at all to do with RELENG_X _per_ _se_, as it applies equally to X-RELEASE, and also to any production systems running any other OS. Before we roll out a new RELENG_6 build, we test it first to discover any potential problems -- but this is standard practice for _everything_ that goes into production, including changes to Linux, Solaris, and Windows systems, and also changes to samba, apache, or any other software running on the systems. My point here is that it is the grabbing something and throwing it into production without testing that is insanity, and that this has nothing specifically to do with RELENG_6. I might also add that I have machines that grab (actually, pretty much randomly -- that is, on a given day and without particular concern from me) RELENG_6 and RELENG_7, and even these machines very rarely exhibit any problems. Of course, these are just test machines, and without the full pre-production testing it is possible that there are some problems in these cases that just don't manifest themselves, but my experience (and, I suspect, that of many others) indicates that your description of RELENG_6 as a seething cauldron of uncertainty is inaccurate. I'm struggling to find a phrase here that can't be taken to be an insult, so forgive me and try to understand when I say that you really should try watching the cvs tree for a bit before making a nonsense comment like that. You don't seem to have struggled very hard. After all, you could have mad the same point by noting that you consider it a mistake to run RELENG_6 in production. And by not doing this, you have undermined your own position, as it seems clear that there are _many_ people and organizations who run RELENG_6 in production (by which I mean, some version of RELENG_6, and not the tracking of daily changes to RELENG_6), which means that your assertion that such is nonsense is itself mistaken. Somewhat more generally, this sort of thing may be why you are getting the amount of push-back you see. That is, what you are claiming seems to match the experience of few (if any) others. As you may have noticed from this thread, the general view (a consensus, seemingly, apart from yourself) is that 6.3 is _better_ (more stable, etc.) than 6.2. Given that such is the case (as it seems very much to be), then the response to your statement that 6.3 isn't good enough of what exactly is wrong? seems (at least to me) to be entirely reasonable. When one of my people comes to me and says that something is wrong with X (and particularly when my experience is that there is nothing wrong with X), my first response is almost invariably: what, specifically, is wrong with X? -- 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]
CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On 6/8/08, Freddie Cash fjwcash at gmail.com wrote: On 6/7/08, Jo Rhett jrhett at netconsonance.com wrote: The question I raised is simply: given the number of bugs opened and fixed since 6.3-RELEASE shipped, why is 6.3 the only supported version? Why does it make sense for FreeBSD to stop supporting a stable version and force people to choose between two different unstable versions? Is this really the right thing to do? Define the terms stable and unstable, how you measure said stability and instability, and what you are comparing them against. This whole discussion is really interesting as it clearly showcases two common trends in computing (rapid development vs stability) On the one side we got people (let's call them developers or computer scientists) who are more interested in development than stabilization of the existing code base. It's natural for them to think more about new features, researching new ideas and implementing them. It resembles an academic project, research project.Those computer scientists do not care much about stability, they are mainly interested in hacking on the code for the fun of it. It is open source after all as someone wisely remarked. From my own experience most if not all community based projects are more interested in following this trend than stabilization of the code. Although they do care about stability of their code base, their focus is more on implementing new features and moving rapidly forward. In today's quickly changing world we see this trend as prevailing. On the other hand though, there is a trend which focuses on maximum long term stabilization of the code base. Usually we see this trend in high end commercial companies serving the needs of mission critical businesses where even a minute of downtime can cause loss of thousands of dollars or even loss of lives of people (imagine stock exchanges, banks, financial insurance institutions, army and police facilities, hospitals, nuclear plants etc.). Those types of businesses/institutions truly needs a maximum stable operating system. They really do not care about new features, but they do care about maximum stability of the existing code, security, and nonstop business continuity even in the face of natural disasters. There is only one operating system I know of that survived 9/11 attacks - this is OpenVMS. It's not uncommon to see VMS uptimes of more than 10 years (you can ask Amsterdam police for evidence). Now that is a true stability! On the other note though, stability is the direct opposition of development and change. Something which is *stable* cannot change or must change very slowly in the long term. On the other hand something which is changing rapidly cannot by the very definition of it be stable but rather is...unstable. Plato said it very wisely in Timaeus: What is that which always is and has no becoming; and what is that which is always becoming and never is?. In other words one could say - what is that which is always the same and stable and what is that which is always changing and is unstable? This elaborate thinking is directly connected even with the trends in todays computing. When the code base is changing rapidly and quickly you cannot say it's very stable. Something stable is always something heavy tested and unchanging. So on the one hand we got users like Jo who wants long term stabilization, who depends on FreeBSD to run their mission critical systems, and on the other the developers who are more interested in the *development* than maintaining and supporting older releases for many years. I got to agree with the developers -this is open source project with limited resources. In order to offer long term support the whole focus of the project would have to be changed - and you can't force people to do something they don't want to do in the open source world. It's more fun to work on implementing new code, than squashing bugs or fanatically audit the code in search of security flaws in old releases. The open source is moving very rapidly forward and it's not only FreeBSD. Look at Linux. There is more than 10,000 messages each month on LKML. Kernel.org peoples also do not care much about stability (recent problems with vanilla kernels do support my thesis) - they commit so fast and massively that it becomes real hard to maintain this beast even for seasoned hackers. But someone who is sane will not be using kernel.org kernels in mission critical production environments but rather commercial distro kernels like Red Hat's versions. Also they won't be using 8-CURRENT on production systems either. Those are more research projects than operating environments for data centers. But when Red Hat is taking kernel.org kernel and put it out as part of their distro they give 7 (read: seven) years support for that particular kernel, userland and any third party application they support. They backport all security and bug fixes to the so called stable release during those seven years.
Re: cpufreq broken on core2duo
On Sat, Jun 07, 2008 at 11:05:44PM +0300, Evren Yurtesen wrote: I have tested if it is working or not without using powerd. However you are right, SpeedStep in bios seem to be adding some ACPI support which looks like kind of broken. In either case, I get error when I have HTT as powerd (powerd -v) is only able to change 1 CPUs speed (obviously). Perhaps this can be fixed in future hopefully. I believe you can only adjust the clock frequency of both CPUs/cores on Intel platforms. At least that's how it is under Windows, and under PC BIOSes. If you have a CPU that has dual cores, both cores will have their frequency adjusted. If you have dual physical CPUs that have dual cores, any frequency adjustment should apply to all CPUs. In the bios, there is also Enhanced C1 support which seems to be reducing the vcore voltage at the same clock speed. (is this normal even?) Enhanced C1 support allows the CPU to go into a deeper sleep state during idle periods. I recommend enabling it, even on server systems. You can safely enable it on systems using FreeBSD. You might be interested in the utility for Windows called RMClock, which provides an incredible amount of low-level information about CPUs and chipsets. Yes, I know it's for Windows, but if you ever boot Windows, it's a fantastic utility. This is the motherboard (information from the datacenter): http://www.supermicro.com/products/motherboard/PD/E7230/PDSML-LN2.cfm Although kenv | grep smbios show PDSBM can this be or the datacenter is wrong? I can add support for this motherboard to bsdhwmon(8), assuming you can get me a few pieces of information. (Edit: Actually, seems you've already contacted me with this information! Thanks!) I'll need to contact Supermicro to get Winbond interface details, however. That can take a couple weeks. I just went to bios and says 1.264v so I guess it is safe to assume that mbmon was showing double. mbmon is showing you invalid values. The fact that it's a value that happens to be double in value is pure chance. mbmon is not properly working with your motherboard. It's that simple. :-) -- | 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: kernel panic on em0/taskq
On Sat, Jun 07, 2008 at 11:34:41PM +0200, Daniel Ponticello wrote: Hello, i'm experiencing periodic kernel panics on a server with FreeBSD 7.0-STABLE #0: Tue May 20 19:09:43 CEST 2008. My big problem is that the system is not performing memory dumping and/or automatic reoboot, it just stays there. Try adjusting some of these sysctl values: hw.acpi.disable_on_reboot hw.acpi.handle_reboot You're using VMware, which may or may not behave properly anyways. -- | 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: console access
On Sun, 8 Jun 2008, Andrew Snow wrote: Andy Kosela wrote: Then you can even remotely mount iso images from your laptop at home directly on the server (very handy sometimes). Incidentally, when I tried to use a Supermicro IPMI card for networked remote media, FreeBSD boot loader crashed the machine (video went haywire and it didnt boot). The same thing happened when trying to use a USB CDROM drive, so I suspect USB boot support is at fault somehow. Try a snapshot made after this commit.. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/i386/btx/btx/btx.S?rev=1.46;content-type=text%2Fx-cvsweb-markup (it was MFC'd to RELENG_6 others on the 18th of March) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: console access
On Sun, Jun 08, 2008 at 07:53:32PM +1000, Andrew Snow wrote: Andy Kosela wrote: Then you can even remotely mount iso images from your laptop at home directly on the server (very handy sometimes). Incidentally, when I tried to use a Supermicro IPMI card for networked remote media, FreeBSD boot loader crashed the machine (video went haywire and it didnt boot). Supermicro IPMI cards are notoriously buggy. A few of the system engineers at Yahoo! who I know continually bitch and moan about how horrible they are. My advice: do not install the IPMI card which is causing your problems. Additionally, the IPMI card which piggyback on top of one of the onboard Ethernet ports are going to force the use of something called ASF (at least in Broadcom land it's called that), where the NIC then has two physical MAC addresses -- yes, you read that right! The OS has to have support for that feature for it to work properly, and your local LAN will probably freak out, ARP-wise. The same thing happened when trying to use a USB CDROM drive, so I suspect USB boot support is at fault somehow. Booting FreeBSD off of USB devices is known to be broken; see BTX, boot2, and loader section at the below URL: http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues -- | 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: console access
Jeremy Chadwick wrote: Supermicro IPMI cards are notoriously buggy. A few of the system engineers at Yahoo! who I know continually bitch and moan about how horrible they are. My advice: do not install the IPMI card which is causing your problems. The remote KVM control feature was an important requirement so the card is staying. Luckily it uses the Intel gigabit NIC which seems to work well in 7-STABLE, I have no complaints so far. Every feature works well except virtual media. Booting FreeBSD off of USB devices is known to be broken; see BTX, boot2, and loader section at the below URL: http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues Thats interesting - I regularly use USB sticks to boot freebsd as its easier for installation on cluster machines/routers that lack CDROM drives. I've used it on, I think, half a dozen different motherboards/architectures and its worked well on all of them, the Supermicro box was the only broken one. Because virtual media emulates a USB device I'm pretty sure thats why it wasnt working - the USB problem, not a problem with the IPMI card. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic on em0/taskq
Hello, disabling acpi is not an option, since i'm running SMP. I have several other systems running 7.0 Release without problems, so it might be something on 7-Stable. Thanks, Daniel Jeremy Chadwick ha scritto: On Sat, Jun 07, 2008 at 11:34:41PM +0200, Daniel Ponticello wrote: Hello, i'm experiencing periodic kernel panics on a server with FreeBSD 7.0-STABLE #0: Tue May 20 19:09:43 CEST 2008. My big problem is that the system is not performing memory dumping and/or automatic reoboot, it just stays there. Try adjusting some of these sysctl values: hw.acpi.disable_on_reboot hw.acpi.handle_reboot You're using VMware, which may or may not behave properly anyways. -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic on em0/taskq
Sorry, I did not read well you suggestion ;) Anyway, the system reboots correctly if I issue the reboot command from command line. Should i adjust those values anyway? Thanks, Daniel Daniel Ponticello ha scritto: Hello, disabling acpi is not an option, since i'm running SMP. I have several other systems running 7.0 Release without problems, so it might be something on 7-Stable. Thanks, Daniel Jeremy Chadwick ha scritto: On Sat, Jun 07, 2008 at 11:34:41PM +0200, Daniel Ponticello wrote: Hello, i'm experiencing periodic kernel panics on a server with FreeBSD 7.0-STABLE #0: Tue May 20 19:09:43 CEST 2008. My big problem is that the system is not performing memory dumping and/or automatic reoboot, it just stays there. Try adjusting some of these sysctl values: hw.acpi.disable_on_reboot hw.acpi.handle_reboot You're using VMware, which may or may not behave properly anyways. -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
pkg_delete core dump when removing linux-tiff
Hi! pkg_delete core dumps on me when it tries to remove linux-tiff. I can reproduce this reliably. nirvana# pkg_delete linux-tiff-3.7.1 pkg_delete: file '/compat/linux/usr/bin/bmp2tiff' doesn't exist pkg_delete: file '/compat/linux/usr/bin/fax2ps' doesn't exist pkg_delete: file '/compat/linux/usr/bin/fax2tiff' doesn't exist pkg_delete: file '/compat/linux/usr/bin/gif2tiff' doesn't exist pkg_delete: file '/compat/linux/usr/bin/pal2rgb' doesn't exist pkg_delete: file '/compat/linux/usr/bin/ppm2tiff' doesn't exist pkg_delete: file '/compat/linux/usr/bin/ras2tiff' doesn't exist pkg_delete: file '/compat/linux/usr/bin/raw2tiff' doesn't exist pkg_delete: file '/compat/linux/usr/bin/rgb2ycbcr' doesn't exist pkg_delete: file '/compat/linux/usr/bin/thumbnail' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiff2bw' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiff2pdf' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiff2ps' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiff2rgba' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffcmp' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffcp' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffdither' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffdump' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffinfo' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffgt' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffmedian' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffset' doesn't exist pkg_delete: file '/compat/linux/usr/bin/tiffsplit' doesn't exist pkg_delete: file '/compat/linux/usr/lib/libtiff.so.3' doesn't exist pkg_delete: file '/compat/linux/usr/lib/libtiff.so.3.7.1' doesn't exist pkg_delete: file '/compat/linux/usr/share/doc/libtiff-3.7.1/COPYRIGHT' doesn't exist pkg_delete: file '/compat/linux/usr/share/doc/libtiff-3.7.1/README' doesn't exist pkg_delete: file '/compat/linux/usr/share/doc/libtiff-3.7.1/RELEASE-DATE' doesn't exist pkg_delete: file '/compat/linux/usr/share/doc/libtiff-3.7.1/VERSION' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/bmp2tiff.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/fax2ps.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/fax2tiff.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/gif2tiff.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/pal2rgb.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/ppm2tiff.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/ras2tiff.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/raw2tiff.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/rgb2ycbcr.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/sgi2tiff.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/thumbnail.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiff2bw.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiff2pdf.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiff2ps.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiff2rgba.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffcmp.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffcp.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffdither.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffdump.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffinfo.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffgt.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffmedian.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffset.1.gz' doesn't exist pkg_delete: file '/compat/linux/usr/share/man/man1/tiffsplit.1.gz' doesn't exist Segmentation fault (core dumped) nirvana# I got caught by this when I was removing a large number of packages using pkg_cutleaves. Not sure why all those files are missing, perhaps pkg_delete removed them the first time before core dumping. It doesn't actually unregister the package. FWIW you can find the core dump here: http://www.hcl-club.lu/~jaj/stuff/pkg_delete.core uname -a FreeBSD nirvana.my.domain 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed May 28 19:35:33 CEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/HYPOCENTER i386 Best regards, Jona -- Pond-erosa Puff wouldn't take no guff Water oughta be clean and free So he fought the fight and he set things right With his OpenBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic on em0/taskq
On Sun, Jun 08, 2008 at 03:07:08PM +0200, Daniel Ponticello wrote: Sorry, I did not read well you suggestion ;) Anyway, the system reboots correctly if I issue the reboot command from command line. Should i adjust those values anyway? I'd recommend adjusting them and see if the bug (not automatically rebooting on panic) changes. I'm guessing it won't (especially if reboot(8) works fine), but it's worth trying. You're the 2nd person I've seen who has reported this problem (re: FreeBSD not properly rebooting on panic). The other person: http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042250.html I'll add this to my Commonly reported issues Wiki. As for the problem itself, sorry, I have no idea what's causing it. -- | 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: console access
On Sun, Jun 08, 2008 at 10:52:37PM +1000, Andrew Snow wrote: Jeremy Chadwick wrote: Supermicro IPMI cards are notoriously buggy. A few of the system engineers at Yahoo! who I know continually bitch and moan about how horrible they are. My advice: do not install the IPMI card which is causing your problems. The remote KVM control feature was an important requirement so the card is staying. Luckily it uses the Intel gigabit NIC which seems to work well in 7-STABLE, I have no complaints so far. Every feature works well except virtual media. Booting FreeBSD off of USB devices is known to be broken; see BTX, boot2, and loader section at the below URL: http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues Thats interesting - I regularly use USB sticks to boot freebsd as its easier for installation on cluster machines/routers that lack CDROM drives. I've used it on, I think, half a dozen different motherboards/architectures and its worked well on all of them, the Supermicro box was the only broken one. Okay, so then your original comment (The same thing happened when trying to use a USB CDROM drive, so I suspect USB boot support is at fault somehow) might actually not be caused by FreeBSD at all? The reason I say that: Because virtual media emulates a USB device I'm pretty sure thats why it wasnt working - the USB problem, not a problem with the IPMI card. What Supermicro box is having USB booting problems? I'm currently in a battle with Supermicro regarding the PDSMi+ not properly booting certain models of USB flash drives: http://koitsu.wordpress.com/2008/04/05/supermicro-pdsmi-bios-bugs/ http://koitsu.wordpress.com/2008/04/26/supermicro-pdsmi-bios-bugs-part-2/ Supermicro currently has both of my USB flash drives which I reported (two different) problems with, and they have confirmed the bug, but are unsure what's causing it. The last time I heard from them was 3 weeks ago, stating we're still working on it. (I'd really like my USB drives back..) I would not be surprised if the same problem affected USB CDROMs. -- | 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: console access
Jeremy Chadwick wrote: Okay, so then your original comment (The same thing happened when trying to use a USB CDROM drive, so I suspect USB boot support is at fault somehow) might actually not be caused by FreeBSD at all? The reason I say that: OK, good point. I didn't try any other OS, I just tried FreeBSD 6 and 7 off a USB CDROM drive, virtual media CDROM, and virtual media floppy, both of which use USB emulation. I assumed that if I tried, say, a Windows CD, it would just work because that's usually Supermicro's target market. What Supermicro box is having USB booting problems? Its a rather new X7DWT motherboard (Intel 5400 chipset, Xeon CPU) Good luck with getting your USB drives back :-) - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: console access
On Sun, 8 Jun 2008, Andrew Snow wrote: Thats interesting - I regularly use USB sticks to boot freebsd as its easier for installation on cluster machines/routers that lack CDROM drives. I've used it on, I think, half a dozen different motherboards/architectures and its worked well on all of them, the Supermicro box was the only broken one. Because virtual media emulates a USB device I'm pretty sure thats why it wasnt working - the USB problem, not a problem with the IPMI card. Lucky you, every system I've tried it on bar my Dell i8600 laptop failed to boot :) With the btx.S r1.46 commit I was much more successful though. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: pkg_delete core dump when removing linux-tiff
Jona Joachim wrote: Hi! pkg_delete core dumps on me when it tries to remove linux-tiff. I can reproduce this reliably. FWIW you can find the core dump here: http://www.hcl-club.lu/~jaj/stuff/pkg_delete.core You need to obtain the backtrace, see the developers handbook. 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 Thu, 5 Jun 2008, Chris Marlatt wrote: Adrian Chadd wrote: The project is doing what it can with what people are contributing. If What if it can accomplish the same or more by simply reorganizing what it's already doing? I completely understand the apparent situation - if you look at it from all angles it appears to be no different than that of the people apposed to the recent scheduling changes FreeBSD has made. There's a limited amount of people and time to do everything. It's an order-of-magnitude question. The work required to support a release for 48 months is more than double the work required to support a release for 24 months. The current regular and extended support releases reflect a practical balance with respect to how long a release can be support. We provide a much longer timeline of support for *branches*, however, and that's generally the support mechanism recommended for people looking for 4-6 years of support for a version of FreeBSD. If you look at what other OS vendors do -- Microsoft is a particularly easy example to inspect -- they require occasional large-scale updates while you live on a particular branch. For example, if you're going to keep running Win2k for six years, you must install their service packs, not just hot fixes for specific vulnerabilities. Our minor releases on a branch are a *lot* less disruptive than service packs for Windows, and are much more conservative. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2; 6.3; EOL; combustible discussions
On Sat, 7 Jun 2008, Josh Carroll wrote: While it would be interesting to see the response here, it still doesn't necessarily provide a solution. It will still involved developers' time to QA the user-submitted patches, so it won't entirely eliminate the additional workload for maintainers. There is also zero (enforceable) accountability. If X people commit to this, what happens when only a fraction of them actually do end up helping? Just to be clear here, Adrian's claim that if someone else provided patches for 6.2, they would be committed, is incorrect. The cost of committing the patch is almost zero -- the cost of QA'ing the patch, doing freebsd-update rebuilds, preparing security or errata notices, etc, is extremely real, and the reason that we carefully limit the number of releases we support at once. In fact, I'd argue that we have been supporting too many releases at once, as I think our latency for shipping errata notices and advisories is too high. By reducing the number of releases we support, we improve the speed and attention we can give each notice/advisory, which is an important consideration. Robert N M Watson Computer Laboratory University of Cambridge ___ 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
Andy Kosela wrote: ... a really beutiful and elaborate post on the subject ... However, being an ordinary user with few machines running FreeBSD, i have seen on my limited sample that 2 machines worked better with 6.3 than 6.2 (two old Athlon machines, which work perfectly OK in fact) and one worked much worse (a P4 which used to be perfectly stable and suddenly panicked 3 times in a week). So i upgraded this last one to 7.0 and it is now working perfectly well without any trouble. The only gotcha is the slowness of X problem when compiling, but i live with that. Moral of the story: the developer base of FreeBSD is not large enough to maintain a large number of releases. In my humble opinion, having 8.0 7.0 and 6.* is even too much. The developers are working on 8.0, they still have a very good grasp of 7.0 but 6.* becomes old stuff, more or less forgotten. It then occurs that things are merged to the 6.* branch which are perhaps susceptible of destabilising it. Personnally i have seen the same occurring with 6.0, 5.0 and 4.*, for me the last releases of the 4.* were very poor on my laptop while the early 4.* releases were perfectly OK. I think it is very unreasonable for end users to ask maintaining, e.g. 6.2 ad vitam eternam. The real stable branch is now 7.* and diverting effort to polish the 6.* is a waste of time. People wanting a very stable system should simply use something else, like Debian stable, official RedHat, etc. whose aim is precisely to offer the maximum stability, with only security and bug fixes, and for extended periods of time. The price you pay is obsoleted and unsexy systems, which is probably OK for the intended use. On the other hand i have no business running such a system. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: console access
Jeremy Chadwick wrote: On Sun, Jun 08, 2008 at 07:53:32PM +1000, Andrew Snow wrote: [...] Additionally, the IPMI card which piggyback on top of one of the onboard Ethernet ports are going to force the use of something called ASF (at least in Broadcom land it's called that), where the NIC then has two physical MAC addresses -- yes, you read that right! The OS has to have support for that feature for it to work properly, and your local LAN will probably freak out, ARP-wise. It would be nice to have it better documented in manpage for bge (I know hw.bge.allow_asf is mentioned, but the words does not make it clear to me). It took me a long time before I discovered that I need to add hw.bge.allow_asf=1 in to loader.conf. Since that my eLOM on Sun Fire X2100 M2 servers works nicely without any lockups (mentioned in manpage) The same thing happened when trying to use a USB CDROM drive, so I suspect USB boot support is at fault somehow. Booting FreeBSD off of USB devices is known to be broken; see BTX, boot2, and loader section at the below URL: http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues I am using USB flashdisks with FreeBSD installer with GRUB on HW where older BTX failed. Miroslav Lachman ___ 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
Zoran Kolic [EMAIL PROTECTED] wrote: This thread solves nothing. Two positions are clear. Also, I recall harder words on openbsd list, with a lot shorter thread. The whole thing is finished and should stay in that state. All next posts could be written, but no need to be sent. Aha, perhaps we need to get Theo in to finish it off! Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic on em0/taskq
I just checked the link you have reported. It looks like the problem is present only on SMP machines with both ULE and 4BSD scheduler. I can confirm that the problem is also present on 6.3-Stable. Basically, it freezes before collecting dump and before being able to reboot. I wish i could have more informations to open a PR. Thanks, Daniel Jeremy Chadwick ha scritto: On Sun, Jun 08, 2008 at 03:07:08PM +0200, Daniel Ponticello wrote: Sorry, I did not read well you suggestion ;) Anyway, the system reboots correctly if I issue the reboot command from command line. Should i adjust those values anyway? I'd recommend adjusting them and see if the bug (not automatically rebooting on panic) changes. I'm guessing it won't (especially if reboot(8) works fine), but it's worth trying. You're the 2nd person I've seen who has reported this problem (re: FreeBSD not properly rebooting on panic). The other person: http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042250.html I'll add this to my Commonly reported issues Wiki. As for the problem itself, sorry, I have no idea what's causing it. -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- ___ 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 Sun, Jun 08, 2008 at 12:18:22PM +0100, Steven Hartland wrote: - Original Message - From: Patrick M. Hausen [EMAIL PROTECTED] I have never ever had a single problem caused by running RELENG_N. We changed that only because as the number of machines increases it pays to run the same software on all of them, and RELEASE provides a convenient (!) reference point for that. Yet, if I were affected by a particular bug in RELENG_6_3, I would simply pick my own later reference point at which the bug is fixed. An alternative to this is to maintain a specific set of patches to -RELEASE for only the issues / fixes that you are experiencing. This has worked very well for us over the years so I can recommend it as well. I've done this too. I kept a private 4.8 for years updated with driver and security patches from 4.9 et seq. once 4.8 support was discontinued. Just do the source checkout via CVS and create your own CVS branch. It is more work than I'm prepared for now, where the FreeBSD systems I'm supporting is part-time consulting; that's why I decided to jump to a release line. However, it's a reasonable option for someone who's maintaining their own larger groups of systems. -- 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: console access
--On June 8, 2008 7:53:32 PM +1000 Andrew Snow [EMAIL PROTECTED] wrote: Andy Kosela wrote: Then you can even remotely mount iso images from your laptop at home directly on the server (very handy sometimes). Incidentally, when I tried to use a Supermicro IPMI card for networked remote media, FreeBSD boot loader crashed the machine (video went haywire and it didnt boot). The same thing happened when trying to use a USB CDROM drive, so I suspect USB boot support is at fault somehow. Interesting. I have a umass USB drive that causes kernel panics during boot. The rest of the time it works fine. So, I unplug the USB cable to reboot, then plug it back in and mount the drive after I login. Paul Schmehl If it isn't already obvious, my opinions are my own and not those of my employer.
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 is 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: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
--On June 8, 2008 1:49:35 PM +0200 Andy Kosela [EMAIL PROTECTED] wrote: FreeBSD has always been known for its legendary stability and mature code base which is why many commercial companies depend on it every day. The anomaly as someone said of long term support for 4.x releases only helped to see FreeBSD as more stable and viable solution than Linux by many businesses. Mission critical systems needs long term support (read: at least backporting security patches) and stable systems that can run for years without interruption. When it comes to stability vs development maybe there is time to rethink FreeBSD overall strategy and goals. Major companies using FreeBSD in their infrastructure like Yahoo! or Juniper Networks would definetly benefit from such moves focused on long term support of stable releases. I honestly think it is in their interest to support, even financially Interesting thoughts. Maybe the time is ripe for a RedHat-like support company for FreeBSD. Paul Schmehl If it isn't already obvious, my opinions are my own and not those of my employer.
Re: 6.2; 6.3; EOL; combustible discussions
--On June 8, 2008 4:52:36 PM +0100 Robert Watson [EMAIL PROTECTED] wrote: Just to be clear here, Adrian's claim that if someone else provided patches for 6.2, they would be committed, is incorrect. The cost of committing the patch is almost zero -- the cost of QA'ing the patch, doing freebsd-update rebuilds, preparing security or errata notices, etc, is extremely real, and the reason that we carefully limit the number of releases we support at once. In fact, I'd argue that we have been supporting too many releases at once, as I think our latency for shipping errata notices and advisories is too high. By reducing the number of releases we support, we improve the speed and attention we can give each notice/advisory, which is an important consideration. What would be the most beneficial boost to FreeBSD? Would it be cash? Additional developers? Does FreeBSD have anyone who works fulltime (IOW, is paid)? Would more fulltime workers alleviate the issues you've articulated? Paul Schmehl If it isn't already obvious, my opinions are my own and not those of my employer.
Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
--On June 8, 2008 5:49:20 PM +0200 Michel Talon [EMAIL PROTECTED] wrote: I think it is very unreasonable for end users to ask maintaining, e.g. 6.2 ad vitam eternam. The real stable branch is now 7.* and diverting effort to polish the 6.* is a waste of time. People wanting a very stable system should simply use something else, like Debian stable, official RedHat, etc. whose aim is precisely to offer the maximum stability, with only security and bug fixes, and for extended periods of time. The price you pay is obsoleted and unsexy systems, which is probably OK for the intended use. On the other hand i have no business running such a system. Please do understand that for some of us, these are not choices. I wiped a FreeBSD machine and bought and installed RedHat because a vendor's software would only run on RedHat. The experience was a painful one. RedHat's updates are a pure PITA. The box now runs FreeBSD again, and I doubt I will ever experiment with something else again. If I can't have FreeBSD, I won't run a server. I don't think I'm alone. Paul Schmehl If it isn't already obvious, my opinions are my own and not those of my employer.
Re: 6.2; 6.3; EOL; combustible discussions
On Sun, Jun 08, 2008 at 10:17:20AM +0800, Adrian Chadd wrote: Ok everyone, I think thats enough about this for now. I think the developers and users have made their points clear, and they're no going to agree any more (but they may agree less) over time. Well, *please* don't assume all users agree with Jo. Some of us actually read the EOL date on 6.2, assumed it meant what it said, and made an informed decision to use 6.2 as the best candidate available at that date, even knowing we'd be forced to upgrade sooner rather than later. If as an admin/user I could give a message to the developers, it would be a very different one: I would like to one day see a -STABLE line, perhaps 8.x, perhaps later, which would by *design* be strong enough and incorporate enough flexibility in its core design that it could be continued for as many as 5 years of minor releases (rather than by *default* as 4.x was due to the difficulty of the SMP model transition and the 5.x stability problems.) If I knew that were an eventual development goal, I'd be even happier with the FreeBSD development team. I have no damn idea how to achieve that goal, and as a software developer I know it's ridiculously, insanely difficult to design to a goal like that, but I do think that continuation is one of the main factors behind the nostalgia for the 4.x line. -- 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: Lenovo Thinkpad t61p and FreeBSD?
On Sunday 08 June 2008 02:03:33 pm Alexandre Sunny Kovalenko wrote: 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 is from the referenced message forward. HTH, So in doing some more research I finally got together the nerve to disassemble my laptop. After cleaning a massive amount of thermal paste off the cpu and heatsink it's operating around 60C after multiple make -j4 buildworlds, where it used to shut down due to going over 100C. It seems I'm not the first person to discover this was the root cause of their heat and noise problems with their Lenovo T60/61 laptop. I've also been able to turn over control of the fan back to the BIOS as opposed to running it full out all the time. -- 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: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On 2008-Jun-08 17:49:20 +0200, Michel Talon [EMAIL PROTECTED] wrote: and it is now working perfectly well without any trouble. The only gotcha is the slowness of X problem when compiling, but i live with that. Have you tried SCHED_ULE? In my experience, it does a better job of scdeduling than SCHED_4BSD, even on UP machines (YMMV). which are perhaps susceptible of destabilising it. Personnally i have seen the same occurring with 6.0, 5.0 and 4.*, for me the last releases of the 4.* were very poor on my laptop while the early 4.* releases were perfectly OK. The difficulty with the later 4.x releases was that there were major differences between the 4.x and later kernels and this made it increasingly difficult to backport bugfixes. This is less of an issue with now 4.x is out of the way. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpmjvNkZtFUJ.pgp Description: PGP signature
Re: Current status of support for high end SAN hardware
Andy I am currently using HP MSA1500cs SAN setups on FreeBSD 7 and 6.3 using qlogic cards in HP DL380G4 and G5 servers. I am not yet using multipath fiber channel which is supported in 7 and I want to test this out soon. As for Redhat ES 4 and 5 I am also using the same hardware setup , I have to say that RedHat ES4 works better for me the Enterprise 5 . ES5 has some odd ball networking issues, when you upgrade from say update 0 - 1 or 1 - 2. For some reason Redhat decided that it needed to remove your configs for eth0 as part of the upgrade. I would say to look at using 64Bit FreeBSD 7-RELEASE and ZFS as the filesystem on the SAN. ZFS is hands down better then EXT3+LVM . Andy Kosela wrote: Hi all, What is the current status of support for high end SAN hardware in FreeBSD? I'm especially interested in support for HP EVA/XP disk arrays, Qlogic HBAs, multipathing. How FreeBSD compares in this environment to RHEL 5? -- Andy Kosela ora et labora ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Saad Managed UNIX Support DataPipe Managed Global IT Services () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/emaildisclaimer.aspx for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On Sun, 8 Jun 2008, Andy Kosela wrote: Define the terms stable and unstable, how you measure said stability and instability, and what you are comparing them against. This whole discussion is really interesting as it clearly showcases two common trends in computing (rapid development vs stability) On the one side we got people (let's call them developers or computer scientists) who are more interested in development than stabilization of the existing code base. It's natural for them to think more about new features, researching new ideas and implementing them. It resembles an academic project, research project. ... On the other hand though, there is a trend which focuses on maximum long term stabilization of the code base. Usually we see this trend in high end commercial companies serving the needs of mission critical businesses where even a minute of downtime can cause loss of thousands of dollars or even loss of lives of people (imagine stock exchanges, banks, financial insurance institutions, army and police facilities, hospitals, nuclear plants etc.). Those types of businesses/institutions truly needs a maximum stable operating system. They really do not care about new features, but they do care about maximum stability of the existing code, security, and nonstop business continuity even in the face of natural disasters. I think there are some important truths to your observations, but let me present a contrarian view: I think you are presenting a false dichotomy, unnecessarily pitting developers and users at odds with respect to the goals of the project. There are definitely points of conflict along these lines, but much of the time the reason that people use FreeBSD is precisely because there *is* agreement on these points. There are many FreeBSD developers who work on FreeBSD precisely because their employer uses FreeBSD, and hence directly represent interests of long-term support, stability, etc. And indeed, as you observe, these are the interests of large web hosts, appliance companies, etc, being required to build their products. We have a highly branched development in order to reflect the varying degrees of both investment in and tolerance for different levels of feature development vs. stability. If FreeBSD developers only hung around to do adventurous new feature development, we wouldn't have -STABLE branches, errata/security branches, freebsd-update, and so on. Instead, we have a very large infrastructure and a lot of developer time invested in those areas, and this has been growing over time. For example, we introduced RELENG_X_Y errata/security branches in the 4.x timeframe to better serve communities with a low tolerance for feature change. Prior to that time, users had to directly manage patches themselves if they wanted to avoid sliding forward on -STABLE. Likewise, in the mid-5.x timeframe, we added Perforce so that developers wanting to work on projects with very high levels of instability could do so without disrupting HEAD as much, which both improved the pace of development and lead to a more stable product by avoiding allowing the HEAD to become extremely unstable. The recent and rather contentious discussion is not taking place because FreeBSD developers feel that, philosophically, longer support timelines for releases are undesirable. Rather, the argument being made is that, given the underlying assumption of finite resources already committed to particular ends, we should moderate the degree to which we support old releases so that we can keep producing new ones. Don't think that the same trade-offs and hard choices don't have to be made in the development HEAD: in the past, we've pushed back several major features over time due to concerns about stability or availability of developers, which have been far more contentious. Just a thought... :-) Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On Mon, Jun 09, 2008 at 06:55:06AM +1000, Peter Jeremy wrote: On 2008-Jun-08 17:49:20 +0200, Michel Talon [EMAIL PROTECTED] wrote: and it is now working perfectly well without any trouble. The only gotcha is the slowness of X problem when compiling, but i live with that. Have you tried SCHED_ULE? In my experience, it does a better job of scdeduling than SCHED_4BSD, even on UP machines (YMMV). Yes, i run with SCHED_ULE, the machine is less interactive than with 6.2 when compiling, but, as i said, i don't care much about that. What i really don't like is panicking, and with 7.0 my machine is perfectly stable. On the other hand, many tasks run very fast under 7.0, so, overall i am very happy with this version. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On Sun, Jun 8, 2008 at 4:49 AM, Andy Kosela [EMAIL PROTECTED] wrote: On 6/8/08, Freddie Cash fjwcash at gmail.com wrote: On 6/7/08, Jo Rhett jrhett at netconsonance.com wrote: The question I raised is simply: given the number of bugs opened and fixed since 6.3-RELEASE shipped, why is 6.3 the only supported version? Why does it make sense for FreeBSD to stop supporting a stable version and force people to choose between two different unstable versions? Is this really the right thing to do? Define the terms stable and unstable, how you measure said stability and instability, and what you are comparing them against. This whole discussion is really interesting as it clearly showcases two common trends in computing (rapid development vs stability) Like I said, you have to define what you mean by stable and unstable before the discussion can continue. stable can mean many things to many people. You talk about feature stability. Other may talk about number of open bugs as being unstable. Others may talk of API/ABI stability. Other may mean code that don't crash a system. Your view of stable meaning features don't change is no where near my definition of stable (systems that don't crash, and where I can run binaries from older point releases on newer point releases). The joy of English is that words are overloaded with multiple meanings. And until everyone agrees on which meaning of the words they are using, there's very little point in discussing things ... as everyone will be talking about something different. -- Freddie Cash [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: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On Sun, 8 Jun 2008, Freddie Cash wrote: Define the terms stable and unstable, how you measure said stability and instability, and what you are comparing them against. This whole discussion is really interesting as it clearly showcases two common trends in computing (rapid development vs stability) Like I said, you have to define what you mean by stable and unstable before the discussion can continue. stable can mean many things to many people. You talk about feature stability. Other may talk about number of open bugs as being unstable. Others may talk of API/ABI stability. Other may mean code that don't crash a system. Your view of stable meaning features don't change is no where near my definition of stable (systems that don't crash, and where I can run binaries from older point releases on newer point releases). I think very few companies that use FreeBSD want it to be like OpenVMS -- otherwise they'd be using OpenVMS. Companies, and users generally, come to FreeBSD not just because they want system stability over time, but also because they expect us to keep producing new (yet mature) features. Sure, they may claim otherwise, but in practice they discover they do want FreeBSD to support the latest rev of an ethernet chipset on a motherboard because the replacement parts they received from their hardware vendor have it, support for larger disk sizes, support for a new POSIX API, being able to boot on systems that require (rather than just support) ACPI, etc. And those changes, perhaps individually incremental, add up to significant changes requiring new releases quite quickly. Again, I wouldn't argue that we couldn't further improve things, but at the same time, we have to recognize that any discussion about improvement in a world of finite resources requires a change in the set of trade-offs we accept. This is one reason why such discussions get contention, because one person's easy win from a change becomes another person's loss. Robert N M Watson Computer Laboratory University of Cambridge ___ 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?
Date: Wed, 04 Jun 2008 10:01:47 -0700 From: Doug Barton [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] 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. Amen, Doug. I post this advise fairly routinely. For my ThinkPad, I just remove the keyboard (4 screws) and blow into the exhaust ports. I know that I would be better off with compressed air, but my lungs are hand and available and, the small amount of contamination they input is dwarfed by the massive cloud of dust that blasts out of the air intake in the heat sink assembly. Low tech and only takes about 15 minutes. I do it annually or when the CPU temp hits 90 during a big build (such as buildworld or gnome). -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgp68bGp6S2Et.pgp Description: PGP signature
Re: challenge: end of life for 6.2 is premature with buggy 6.3
Y'know, I've been sort of skimming this thread, and I think a lot of this time could be better spent by just looking at the PRs and giving the original poster tips and encouragement for providing the information needed by FreeBSD to solve his problems. Really... -Alfred * Mike Edenfield [EMAIL PROTECTED] [080605 18:04] wrote: Paul Schmehl wrote: I think that's an unfair characterization. He stated that he had noted numerous bugs in 6.3 (submitted PRs) that he perceived affected him personally and so he chose not to update to 6.3. He then asked if 6.2 couldn't be extended farther. That seems like a reasonable question to ask. A simple, professional answer would have settled the matter quickly. Part of the problem is that a few of us (including myself) *have* looked for the PRs he referenced and can't find them. There are only three critical PR's opened on the hardware devices he mentioned that are filed specifically against version 6.3: one each for bge, gmirror, and 3ware. Of those, one of them appears to be sporadic, one of them appears to be specific to a particular obscure BIOS, and one of them involved a specific dual-card setup on a specific type of motherboard. And none of those *specifically* say that they cannot be reproduced on 6.2 -- one of them is actually filed against version 5 through 7. Since we also know very little about the specific hardware setup of the OP, it's impossible to determine if these are, in fact, the PRs he's looking at, or if he's actually looking at other less-critical PRs that may need to be bumped up to critical, or if they're misfiled, or who knows what. In short, the problem reports that the OP is looking at are not immediately obvious to someone who doesn't already know what they are, and he's not doing himself any favors by insisting that everyone else already knows about these problems. If he's seen these bug reports, presumably he knows what their PR #'s are, or at the very least the description of the bugs, and it would be many many times faster for him to just say so than continue to insist that other people read his mind. --Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- - 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
* Jo Rhett [EMAIL PROTECTED] [080607 14:37] wrote: Mike, could you do me a favor and provide me with a set of words that will make what I am trying to say on this topic clear? I keep saying the same thing over and over again and nobody is hearing me, so could you perhaps help me translate this? These are the raw issues without any friendly wording. 1. Bugs in 6.3 that are patched aren't available in any other -RELEASE. Jo, sorry to jump in here, but what are these bugs that you are concerned about? Can you give specific PR#s? Can you confirm that these bugs are still issues? 2. Bugs in 6.3 outstanding that don't affect 6.2 This is a bit of a stretch honestly, there may be bugs in 6.3 that are also in 6.2, however they have only been reported in 6.3 because of time. 3. Overall amount of bugs. See previous. 4. Difference in code base between 6.3 and 6-STABLE is than 6.2 and 6.3 Well, that's good! (or should be, see below.) These combine to produce a release which will never be stable for production needs. Let's not go there. Let's work with what we have. In theory people should only be pushing bugfixes and drivers in the -stable series, however sometimes changes are made for performance too when the risk is low. Larger changesets in the later versions of -stable for a particular major release is to be expected as the number of users migrating from the previous major release (5.x) start to come over. Obviously the FreeBSD team(s) involved have to make choices. Perhaps there's nothing we can do to improve it other than work on the specific bugs. But does it hurt to ask why 6.2 was dropped so fast? What the real cost of supporting 6.2 until 6.4 ships is? I can understand your upset, I have been there, I found that later versions of 5.x had regressions for me that forced me to decide to either downgrade to 5.3 or go to 6.x. You may need to stick to 6.2 and keep a local set of patches (this is much easier now with svn and svk). OR you can try 7.x. The fact of the matter is that as an individual you have many options: 1) work to figure out why 6.3 (or -stable) isn't working. 2) stick with 6.2 with your own mods. 3) try 7-stable. Trust me, I know you've been pretty frustrated by this thread, but from my experience you're not going to get what you want, but you may get what you need (if you take my advice). best of luck, -Alfred ___ 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 Sun, 8 Jun 2008, Alexandre Sunny Kovalenko wrote: 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 is from the referenced message forward. Hi Alex, glad to see you're still keeping track of these issues .. In there ume@ says that his patch was committed .. do you know if it was MFC'd back to 7.x? 6.x? Perhaps the docs haven't caught up yet? There are only going to be a lot more of these around .. cheers, Ian ___ 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
Date: Sat, 7 Jun 2008 09:48:12 -0700 From: Jeremy Chadwick [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] On Sat, Jun 07, 2008 at 05:51:38PM +0300, Evren Yurtesen wrote: By the way, there is another thing I am wondering about. If I enable HTT and Intel Enhanced SpeedStep in bios on a 3.00GHZ p4 CPU I see: cpu0: ACPI CPU on acpi0 acpi_perf0: ACPI CPU Frequency Control on cpu0 p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 est1: Enhanced SpeedStep Frequency Control on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr f270f27 device_attach: est1 attach returned 6 p4tcc1: CPU Frequency Thermal Control on cpu1 dev.cpu.0.freq_levels: 1500/27000 1312/23625 1200/13000 1050/11375 900/9750 750/8125 600/6500 450/4875 300/3250 150/1625 dev.acpi_perf.0.freq_settings: 1500/27000 1200/13000 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 dev.cpufreq.1.%driver: cpufreq dev.cpufreq.1.%parent: cpu1 dev.p4tcc.0.freq_settings: 1/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.1.freq_settings: 1/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 and it does not allow me to set the freq. of the cpu. How are you setting the frequency? Are you using powerd? You do not have to enable SpeedStep in your BIOS to achieve throttling CPU clock speed. In fact, I would highly recommend leaving EIST/SpeedStep in the BIOS *disabled*, and let powerd adjust the clock frequency via ACPI. I must strongly recommend against this. EST is MUCH more efficient on its control of power use than simple throttling. So much so that on my systems that support EST, I remove cpufreq from the kernel. (In all cases, throttling means either simple throttling or throttling by using TCC.) I did quite a bit of testing on power management a year or so ago and found that throttling was of value only for controlling CPU temperature. For real power management, EST works far better as it adjust frequency (actual clock rate) and CPU voltage while throttling just stops and starts the clock without changing its actual frequency. (This came as a surprise to me about 5 years ago when I first discovered it.) At idle, throttling does exactly nothing. EST reduces voltage on the CPU and saves power even when idle. At full CPU load, throttling reduces performance and power consumption equally. EST beats it by a slim margin. The big win is at moderate load. Throttling can result is very poor results for aps like video and music which will place a continuous load on the system, but only 20-60% (in the case of my test system). It tended to make the system seem sluggish. EST does a much better job in this case as it lowers CP voltage and clock rate to maximize performance while minimizing power. If your only concern is keeping the system cool, throttling will do the job, but if you want efficient power utilization, use EST if possible. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgph8YUcUl48C.pgp Description: PGP signature
Re: cpufreq broken on core2duo
On Sun, Jun 08, 2008 at 10:13:43PM -0700, Kevin Oberman wrote: Date: Sat, 7 Jun 2008 09:48:12 -0700 From: Jeremy Chadwick [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] On Sat, Jun 07, 2008 at 05:51:38PM +0300, Evren Yurtesen wrote: By the way, there is another thing I am wondering about. If I enable HTT and Intel Enhanced SpeedStep in bios on a 3.00GHZ p4 CPU I see: cpu0: ACPI CPU on acpi0 acpi_perf0: ACPI CPU Frequency Control on cpu0 p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 est1: Enhanced SpeedStep Frequency Control on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr f270f27 device_attach: est1 attach returned 6 p4tcc1: CPU Frequency Thermal Control on cpu1 dev.cpu.0.freq_levels: 1500/27000 1312/23625 1200/13000 1050/11375 900/9750 750/8125 600/6500 450/4875 300/3250 150/1625 dev.acpi_perf.0.freq_settings: 1500/27000 1200/13000 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 dev.cpufreq.1.%driver: cpufreq dev.cpufreq.1.%parent: cpu1 dev.p4tcc.0.freq_settings: 1/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.1.freq_settings: 1/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 and it does not allow me to set the freq. of the cpu. How are you setting the frequency? Are you using powerd? You do not have to enable SpeedStep in your BIOS to achieve throttling CPU clock speed. In fact, I would highly recommend leaving EIST/SpeedStep in the BIOS *disabled*, and let powerd adjust the clock frequency via ACPI. I must strongly recommend against this. EST is MUCH more efficient on its control of power use than simple throttling. So much so that on my systems that support EST, I remove cpufreq from the kernel. (In all cases, throttling means either simple throttling or throttling by using TCC.) The reality of the situation is that users cannot use EIST reliably on FreeBSD. I cannot imagine removing cpufreq would solve the runtime went backwards issue. The EIST problem needs to be fixed. If the folks who work on it do not have present-day hardware (C2Ds, etc.), I will be more than happy to purchase them whatever they need. I did quite a bit of testing on power management a year or so ago and found that throttling was of value only for controlling CPU temperature. For real power management, EST works far better as it adjust frequency (actual clock rate) and CPU voltage while throttling just stops and starts the clock without changing its actual frequency. (This came as a surprise to me about 5 years ago when I first discovered it.) As far as I know, the ACPI frequency toggling does in fact adjust the CPU clock rate -- because the values in dev.cpu.0.freq_levels are defined by the ACPI configuration on the machine. I'd confirm this, but looking at the kernel code doesn't help -- I cannot find the definition of the CPUFREQ_LEVELS function or macro. At idle, throttling does exactly nothing. EST reduces voltage on the CPU and saves power even when idle. At full CPU load, throttling reduces performance and power consumption equally. EST beats it by a slim margin. I thought the power-saving modes of the CPU (C1E/C2E/C3E/C4E) could be used *without* enabling EIST. I don't think FreeBSD has kernel or userland support utilities to enable/disable CPU-level features. Something like RMClock for Windows would be quite useful. (If you have the opportunity to run it, do so; you'll see what I mean, re: all the features being toggleable individually). The big win is at moderate load. Throttling can result is very poor results for aps like video and music which will place a continuous load on the system, but only 20-60% (in the case of my test system). It tended to make the system seem sluggish. EST does a much better job in this case as it lowers CP voltage and clock rate to maximize performance while minimizing power. If your only concern is keeping the system cool, throttling will do the job, but if you want efficient power utilization, use EST if possible. In the case est does not attach (e.g. no EIST support enabled in FreeBSD), the throttling method resorts to simply suspending the system, then yes I completely agree -- EIST is significantly better than that. -- | 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]
