Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

freebsd-stable Digest, Vol 349, Issue 8

3 views

Skip to first unread message

freebsd-sta...@freebsd.org

unread,

Mar 28, 2010, 8:00:26 AM3/28/10

to freebsd...@freebsd.org

Send freebsd-stable mailing list submissions to
freebsd...@freebsd.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
or, via email, send a message with subject or body 'help' to
freebsd-sta...@freebsd.org

You can reach the person managing the list at
freebsd-st...@freebsd.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-stable digest..."

Today's Topics:

1. freebsd-update 7.2->7.3 manul merging of all files (Thomas Krause)
2. Re: NFS lockd problem (Chuck Swiger)
3. Re: NFS lockd problem (Jeremy Chadwick)
4. Re: FreeBSD 8.0 SCSI Boot (Peter Jeremy)
5. Re: FreeBSD 8.0 SCSI Boot (Doug Hardie)
6. Re: Powerd and est / eist functionality (John R. Long)
7. Re: Powerd and est / eist functionality (John Long)
8. Re: Powerd and est / eist functionality (Jeremy Chadwick)
9. Re: Powerd and est / eist functionality (John Long)
10. Re: Powerd and est / eist functionality (John Long)
11. Fwd: random FreeBSD panics (Masoom Shaikh)
12. Re: NFS lockd problem (Ronald Klop)
13. Re: NFS lockd problem (Ronald Klop)

----------------------------------------------------------------------

Message: 1
Date: Sat, 27 Mar 2010 16:45:12 +0100
From: Thomas Krause <freebsd...@chef-ingenieur.de>
Subject: freebsd-update 7.2->7.3 manul merging of all files
To: freebsd-stable <freebsd...@FreeBSD.org>
Message-ID: <4BAE2808...@chef-ingenieur.de>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed

Hi,
I want to upgrade a 7.2-RELEASE-p4 to 7.3-RELEASE with the command

# freebsd-update upgrade -r 7.3-RELEASE

After fetching and patching I get

Attempting to automatically merge changes in files... done.

The following file could not be merged automatically: /boot/device.hints
Press Enter to edit this file in vi and resolve the conflicts
manually...

this goes on with *every* file in the /etc directory. What's wrong here?

Best regards,
Thomas.

------------------------------

Message: 2
Date: Sat, 27 Mar 2010 11:50:17 -0700
From: Chuck Swiger <csw...@mac.com>
Subject: Re: NFS lockd problem
To: Giulio Ferro <au...@zirakzigil.org>
Cc: "freeb...@freebsd.org" <freeb...@freebsd.org>,
freebsd...@freebsd.org
Message-ID: <4931283F-5B5B-4368...@mac.com>
Content-Type: text/plain; charset=us-ascii

On Mar 26, 2010, at 3:08 AM, Giulio Ferro wrote:
> Outset:
> 1 NFS server (with lockd)
> 2 NFS client (with lockd)
>
> The clients serve several jails with apache, whose data (www) resides on the server

If you need file locking to work reliably, you pretty much have to give up on using NFS + rpc.lockd and run against a local UFS filesystem.

Regards,
--
-Chuck

------------------------------

Message: 3
Date: Sat, 27 Mar 2010 12:04:39 -0700
From: Jeremy Chadwick <fre...@jdc.parodius.com>
Subject: Re: NFS lockd problem
To: freebsd...@freebsd.org
Message-ID: <20100327190...@icarus.home.lan>
Content-Type: text/plain; charset=us-ascii

On Sat, Mar 27, 2010 at 11:50:17AM -0700, Chuck Swiger wrote:
> On Mar 26, 2010, at 3:08 AM, Giulio Ferro wrote:
> > Outset:
> > 1 NFS server (with lockd)
> > 2 NFS client (with lockd)
> >
> > The clients serve several jails with apache, whose data (www) resides on the server
>
> If you need file locking to work reliably, you pretty much have to give up on using NFS + rpc.lockd and run against a local UFS filesystem.

I thought fcntl(2) worked reliably/properly with NFS on FreeBSD? I
remember reading somewhere how mixing locking types (fcntl vs. flock vs.
lockf) causes major problems, but as long as the same locking method is
used universally things should work...?

------------------------------

Message: 4
Date: Sun, 28 Mar 2010 07:37:49 +1100
From: Peter Jeremy <peter...@acm.org>
Subject: Re: FreeBSD 8.0 SCSI Boot
To: Doug Hardie <bc...@lafn.org>
Cc: FreeBSD-STABLE Mailing List <freebsd...@freebsd.org>
Message-ID: <20100327203...@server.vk2pj.dyndns.org>
Content-Type: text/plain; charset="us-ascii"

On 2010-Mar-26 17:18:30 -0700, Doug Hardie <bc...@lafn.org> wrote:
>I tried to upgrade a 7.2 system to 8.0. It uses a SCSI drive. It
>works fine on 7.2.

We will need some more details before we can help you.

> However, it would appear that during the upgrade
>process when running make delete-old (?) there is a note about make
>delete-old-libs (?). Don't do that at that point. End of system.
>Make installworld fails miserably.

You shouldn't run either "make delete-old" or "make delete-old-libs"
until you have successfully run "make installworld" - the upgrade
procedure shows delete-old after installworld. Whilst delete-old will
just make it harder to revert from a failed upgrade, running
delete-old-libs will prevent you running installworld. When you run
delete-old-libs, it warns you "Please be sure no application still
uses those libraries, else you can not start such an application."
One application that needs the old libraries is installworld.

> Unfortunately rebooting caused numerous problems.

Given that your installworld had failed - presumably leaving various
FreeBSD-7.2 files lying around, whilst you deleted the libraries
required by some of them, this is not surprising.

> First the /etc/fstab was listed as corrupt.

This is surprising. Assuming you cleanly rebooted your system, it
is very unlikely that your /etc/fstab was corrupted and is more likely
a problem with one of the mount programs.

Can you provide the exact error message and what you then did.

> Then it quit booting altogether.

If it rebooted once, there's no reason why it shouldn't reboot a
second time. What actions did you take between the two reboots and
what exactly do you mean by "quit booting"?

> A complete reload from the disc 1 goes
>nowhere either. It installs just fine but when it goes to reboot,
>All I get is F1 followed by a bunch of increasing #s. Any key just
>adds more to the list. I have tried with both the standard and
>FreeBSD boot managers with the same result.

At that point, FreeBSD is using the BIOS drivers to access the SCSI
disk. If you get the 'F1' prompt then the BIOS is correctly loading
the boot sector (so it can access the disk) so there is no obvious
reason why it isn't booting.

Do you have a copy of the dmesg from 7.2? If not, can you give us
some details about your motherboard (vendor/model), what SCSI
controller you are using, what targets are attached and what other
disks (if any) you have. Are you using a PS/2 or USB keyboard?

Can you expand on what you mean by "a complete reload" - did you do a
full install of FreeBSD 8.0, including partitioning and creating disk
slices or did you re-use the existing slices? Are you using a
"dangerously dedicated" disk? Were any disk geometry errors reported?

--
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100327/380530f6/attachment-0001.pgp

------------------------------

Message: 5
Date: Sat, 27 Mar 2010 14:10:25 -0700
From: Doug Hardie <bc...@lafn.org>
Subject: Re: FreeBSD 8.0 SCSI Boot
To: Peter Jeremy <peter...@acm.org>
Cc: FreeBSD-STABLE Mailing List <freebsd...@freebsd.org>
Message-ID: <7E608CAE-2C4D-4C68...@lafn.org>
Content-Type: text/plain; charset=us-ascii

On 27 March 2010, at 13:37, Peter Jeremy wrote:

> On 2010-Mar-26 17:18:30 -0700, Doug Hardie <bc...@lafn.org> wrote:
>> I tried to upgrade a 7.2 system to 8.0. It uses a SCSI drive. It
>> works fine on 7.2.
>
> We will need some more details before we can help you.
>
>> However, it would appear that during the upgrade
>> process when running make delete-old (?) there is a note about make
>> delete-old-libs (?). Don't do that at that point. End of system.
>> Make installworld fails miserably.
>
> You shouldn't run either "make delete-old" or "make delete-old-libs"
> until you have successfully run "make installworld" - the upgrade
> procedure shows delete-old after installworld. Whilst delete-old will
> just make it harder to revert from a failed upgrade, running
> delete-old-libs will prevent you running installworld. When you run
> delete-old-libs, it warns you "Please be sure no application still
> uses those libraries, else you can not start such an application."
> One application that needs the old libraries is installworld.

I know that now. Probably should have before, but didn't figure it out. Not having access to UPDATING made writing the original message a bit difficult. make delete-old was run after make installworld. When it completes it says you can run make delete-old-libs. That is where I made the first mistake. I believe that message is quite misleading and should be removed. The first failure occurred on mergemaster not make installworld. It died on the second install file. The error was something to the effect that rw on /etc/fstab was invalid and gave the sysctl settings to use in boot to get around it. There was nothing other than a reboot possible at that point. There was no other option.

>
>> Unfortunately rebooting caused numerous problems.
>
> Given that your installworld had failed - presumably leaving various
> FreeBSD-7.2 files lying around, whilst you deleted the libraries
> required by some of them, this is not surprising.
>
>> First the /etc/fstab was listed as corrupt.
>
> This is surprising. Assuming you cleanly rebooted your system, it
> is very unlikely that your /etc/fstab was corrupted and is more likely
> a problem with one of the mount programs.
>
> Can you provide the exact error message and what you then did.

that information is long gone.

>
>> Then it quit booting altogether.
>
> If it rebooted once, there's no reason why it shouldn't reboot a
> second time. What actions did you take between the two reboots and
> what exactly do you mean by "quit booting"?

It dies in the boot laoder with F1 followed by numeous #s.

>
>> A complete reload from the disc 1 goes
>> nowhere either. It installs just fine but when it goes to reboot,
>> All I get is F1 followed by a bunch of increasing #s. Any key just
>> adds more to the list. I have tried with both the standard and
>> FreeBSD boot managers with the same result.
>
> At that point, FreeBSD is using the BIOS drivers to access the SCSI
> disk. If you get the 'F1' prompt then the BIOS is correctly loading
> the boot sector (so it can access the disk) so there is no obvious
> reason why it isn't booting.
>
> Do you have a copy of the dmesg from 7.2? If not, can you give us
> some details about your motherboard (vendor/model), what SCSI
> controller you are using, what targets are attached and what other
> disks (if any) you have. Are you using a PS/2 or USB keyboard?

The 7.2 stuff is long gone. The disk has been wiped several times. Until I can get past the F1 issue I don't have access to the hardware information. It uses a PS/2 keyboard and is i386 32 bit. Its an AMD processor thats quite old.

>
> Can you expand on what you mean by "a complete reload" - did you do a
> full install of FreeBSD 8.0, including partitioning and creating disk
> slices or did you re-use the existing slices? Are you using a
> "dangerously dedicated" disk? Were any disk geometry errors reported?

Complete reload means with the live filesystem:

dd if=/dev/zero of=/dev/da0 bs=10240 count=100
Boot from Disc 1
Follow the Standard Install option is sysinstall

I have done that 4 times now. There was a semi-dead ad0 disk in the unit. That has been removed and going through the above one more time at this moment.

There were no errors reportd for disk geometry and its not dangerously dedicated. I gave up with that on version 2.7.

This time it worked. I used the first boot manager entry, not the FreeBSD Boot manager and there is no F1 line. It just boots into FreeBSD. Thats fine since there is only FreeBSD on the machine. I guess something from the ad0 drive was interfering with the boot. The disk was reporting numerous write errors although it could be read fine and was only holding archive'd data. Its loss is insignificant.

I believe the big issue where was the message about make delete-old-libs that make delete-old outputs. I had never tried that before and never had problems. This time I decided to try it. I think that message should be removed.

>
> --
> Peter Jeremy

------------------------------

Message: 6
Date: Sat, 27 Mar 2010 15:23:28 -0700
From: "John R. Long" <joh...@sstec.com>
Subject: Re: Powerd and est / eist functionality
To: Torfinn Ingolfsen <torfinn....@broadpark.no>,
freebsd...@freebsd.org
Message-ID: <5.2.1.1.2.201003...@mail.sstec.com>
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 03:16 AM 3/25/2010, Torfinn Ingolfsen wrote:
>On Wed, 24 Mar 2010 18:04:51 -0700
>John Long <fb...@sstec.com> wrote:
>
>> I want to thank you very much for all the info you have provided. It has
>> clued me into a much better understanding and I see that it is a big
>> un-standard thing to monitor these functions. It seems that things are
>
>FYI: for (some) Asus boards thererb is als acpi_aiboost(4).

I wish I had known that b4. Thanks

>--
>Regards,
>Torfinn Ingolfsen
>
>_______________________________________________
>freebsd...@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"

------------------------------

Message: 7
Date: Sat, 27 Mar 2010 16:51:49 -0700
From: John Long <fb...@sstec.com>
Subject: Re: Powerd and est / eist functionality
To: Jeremy Chadwick <fre...@jdc.parodius.com>
Cc: Alexander Motin <m...@freebsd.org>, FreeBSD-STABLE Mailing List
<freebsd...@freebsd.org>, Ian Smith <smi...@nimnet.asn.au>
Message-ID: <5.2.1.1.2.201003...@mail.sstec.com>
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 02:14 AM 3/26/2010, Jeremy Chadwick wrote:
>On Fri, Mar 26, 2010 at 01:20:19AM -0700, John Long wrote:
>> >Yes you're only getting p4tcc throttling as Alexander points out. You'll
>> >need to get est working to get power reduction from lower frequencies,
>> >which likely won't correspond to these f/8 step throttling frequencies.
>> >
>> >As Jeremy suggested, here's how to turn throttling off, and something
>> >like what you could expect with est working:
>> >http://lists.freebsd.org/pipermail/freebsd-stable/2010-March/055666.html
>>
>> from link:
>> I would recommend you to disable it by setting:
>> hint.p4tcc.0.disabled=1
>> hint.acpi_throttle.0.disabled=1
>>
>> I get unknown oid on both. Not sure how to disable p4tcc here. What
>> I have to work with.
>
>These are /boot/loader.conf tunables, not sysctl. I'm pretty sure I
>stated that in my previous mail...?

Drats, you are right. too late at night.. did not give me anything positive
anyway.
>
>> Bios is most recent, has EIST, c1e and c2e I believe enabled. That
>> seems to do the best all by itself. Maybe It does no good to beat a
>> dead horse?? :-) I see an ITE IT8718F-S chip on board. mbmon does
>> work somewhat but its code is way old and does not see the newer
>> chip versions. some good docs with mbmon in usr/local/share/docs
>> tho..
>> %mbmon -d -A
>> Summary of Detection:
>> * ISA monitor(s):
>> ** Nat.Semi.Con. Chip LM78 found.
>> ** Int.Tec.Exp. Chip IT8705F/IT8712F or SIS950 found
>>
>
>Ignore all of the above values -- mbmon doesn't work properly with your
>board, or that sub-revision of IT chip. It's that simple. Re-read the
>rant I sent you for explanation; I already covered all the bases. :-) I
>disagree about the mbmon docs -- they're more like chaotic brain dumps
>or scribbled notes than actual coherent, well-written instructions or
>details.

Agreed, but they were something vs not much and I was grasping :-)

That said, I have utmost respect for SHIMIZU Yoshifumi and his
>efforts/work.
>
>I'm willing to make an exception here. If you can get the following
>information from the motherboard manufacturer, I'd be willing to add
>support for your board to bsdhwmon. What I need:
>
>1) The exact H/W monitoring IC they use (not what mbmon says, and
> not what's silkscreened on the chip),

That would be a bit impossible for me, what is on the chip is all I can
provide.
>
>2) If the H/W monitoring IC is tied in to SMBus,

hellava question too, Tell me and we would both know :-)
>
>3) What the SMBus slave address is they chose for the H/W IC

% dmesg | grep -i smbus
pci0: <serial bus, SMBus> at device 31.3 (no driver attached)

I am pretty sure I would get a deer in the headlights response from
gigabyte over this question..

>
>4) Output of "kenv | grep smbios" from your system.
> kenv | grep smbios

smbios.bios.reldate="11/04/2009"
smbios.bios.vendor="Award Software International, Inc."
smbios.bios.version="F6"
smbios.chassis.maker="Gigabyte Technology Co., Ltd."
smbios.chassis.serial=" "
smbios.chassis.tag=" "
smbios.chassis.version=" "
smbios.memory.enabled="1048576"
smbios.planar.maker="Gigabyte Technology Co., Ltd."
smbios.planar.product="G41M-ES2L"
smbios.planar.serial=" "
smbios.planar.version="x.x"
smbios.socket.enabled="1"
smbios.socket.populated="1"
smbios.system.maker="Gigabyte Technology Co., Ltd."
smbios.system.product="G41M-ES2L"
smbios.system.serial=" "
smbios.system.uuid="00000000-0000-0000-0000-6cf049635a47"
smbios.system.version=" "
smbios.version="2.4"

1 out of 4 is not too bad :-)
>
>Assuming all of the above meets necessary criteria, I can probably add
>support for this board to bsdhwmon. I have only slight qualms/concerns
>adding consumer boards to bsdhwmon, but the big kicker is that the board
>**must** have an actual H/W monitoring IC tied/wired to SMBus. I *will
>not* use the old LPC/ISA (/dev/io) infrastructure.

I understand, there are just too many possible different implementations
and chips being used. Getting Vcore from both healthd and mbmon, being
about the same and that being the main concern for my discovery into
functionality has me satiated. Getting the rest of the sensors would be
great but certainly would not be worth any effort from you or anyone for
just this one of hundreds of mbds. I do appreciate the offer tho. I should
of bought Asus in the first place. I always have for past 12 years but my
selection dwindled about 3 weeks ago when Frys dropped the asus p5qpl-am.
That was the only non realtek ether g41 mbd I could find. I took a chance
that the re8111 (gigabyte and most others) drivers would work as well and
it looks like they do. The only remaining viable asus mbd, to me, is the
p5g41-m lx2/gm but a search on asus's site and it is not to be found
therefore that would be a nono for me.
There are just too many different mbds out there, the manufs have just gone
hog wild.

>
>> It jumped up in vcore a little there with powerd. C1E and C2E which
>> include P-states are what I am really after and I think that the
>> bios by itself provides those changes better than any other changes
>> in these settings.
>
>...and this would fall under the est(4) subset driver for cpufreq(4).

This repeated clue got me to the next step and I thank you for that. The
key, as I see it, is to get est working either by getting the msr tables
updated somehow or getting the acpi working better so est could fall back
on it therefore powerd would have a better set of signals to use rather
than thermal. Like I have mentioned elsewhere, it looks like est has not
really been updated nor worked on much for about 5 years and is missing the
proper tables for the mbds since. That is a big and near impossible job
unless it can be modded to a sort of wildcard detection if there is some
commonality to newer mbds.

John

>
>--
>| Jeremy Chadwick j...@parodius.com |
>| Parodius Networking http://www.parodius.com/ |
>| UNIX Systems Administrator Mountain View, CA, USA |
>| Making life hard for others since 1977. PGP: 4BD6C0CB |

------------------------------

Message: 8
Date: Sat, 27 Mar 2010 17:42:57 -0700
From: Jeremy Chadwick <fre...@jdc.parodius.com>
Subject: Re: Powerd and est / eist functionality
To: John Long <fb...@sstec.com>
Cc: Alexander Motin <m...@freebsd.org>, FreeBSD-STABLE Mailing List
<freebsd...@freebsd.org>, Ian Smith <smi...@nimnet.asn.au>
Message-ID: <20100328004...@icarus.home.lan>
Content-Type: text/plain; charset=us-ascii

On Sat, Mar 27, 2010 at 04:51:49PM -0700, John Long wrote:
> At 02:14 AM 3/26/2010, Jeremy Chadwick wrote:
> >I'm willing to make an exception here. If you can get the following
> >information from the motherboard manufacturer, I'd be willing to add
> >support for your board to bsdhwmon. What I need:
>
> {snip}
>
> >3) What the SMBus slave address is they chose for the H/W IC
>
> % dmesg | grep -i smbus
> pci0: <serial bus, SMBus> at device 31.3 (no driver attached)

All this means is that there's a SMBus-class device sitting on the PCI
bus which has no driver attached to it. Run "pciconf -lvc" and find the
device in question, and the output relevant to it.

Given the topic of discussion, I'd say your northbridge is Intel-based,
which means you need the smb, smbus, and ichsmb drivers loaded. You can
load these as kernel modules as well. When loading them, do not specify
the trailing ".ko". See the ichsmb(4) man page for some terse details.

Even if you get a driver attached to the SMBus piece of the northbridge,
like I said, there's no guarantee there's a H/W monitoring IC that's
wired to the SMBus. As stated, I don't believe in probing slave
addresses on the SMBus, so the slave address would have to come from
Gigabyte, or...

There's a program for Windows (9x/2K/XP/Vista) called SpeedFan which
does do probing and can/does support SMBus. I have no idea if it works
on Windows 7 or not:

http://www.almico.com/speedfan.php

If SpeedFan shows you all the data you expect/want, and indicates it's
talking to a H/W IC over SMBus, then I could add support for your board
to bsdhwmon (since your motherboard does provide acceptable SMBIOS
tables for identification). I'd still need to know what slave address
the chip had, and what exact model of H/W IC it was. SpeedFan might
provide that.

It would also help (me at least) if you could reboot your system, go
into your BIOS and find whatever menu item is associated with Hardware
Monitoring and write down all of the shown attributes and their values.
What the BIOS shows is what should be accurate above all else.

> >> It jumped up in vcore a little there with powerd. C1E and C2E which
> >> include P-states are what I am really after and I think that the
> >> bios by itself provides those changes better than any other changes
> >> in these settings.
> >
> >...and this would fall under the est(4) subset driver for cpufreq(4).
>
> This repeated clue got me to the next step and I thank you for that.
> The key, as I see it, is to get est working either by getting the
> msr tables updated somehow or getting the acpi working better so est
> could fall back on it therefore powerd would have a better set of
> signals to use rather than thermal. Like I have mentioned elsewhere,
> it looks like est has not really been updated nor worked on much for
> about 5 years and is missing the proper tables for the mbds since.
> That is a big and near impossible job unless it can be modded to a
> sort of wildcard detection if there is some commonality to newer
> mbds.

I can point you to numerous present-day motherboards that work just fine
with cpufreq(4) and est under RELENG_8, and also work when using
acpi_throttle. Specifically, Supermicro PDSMi+, X7SBA, and X7SBL-L2
boards. I'm sure there are many others. In all of these are Core2Duo
or Core2Quad CPUs. An example from the X7SBA system, running powerd:

CPU1 Temperature 41 C
System Temperature 36 C
FAN1 0 RPM
FAN2 0 RPM
FAN3 0 RPM
FAN4 1988 RPM
FAN5 1532 RPM
FAN6 1809 RPM
VcoreA 1.220 V
MCH Core 1.514 V
-12V -11.904 V
V_DIMM 1.712 V
+3.3V 3.360 V
+12V 12.000 V
5Vsb 5.118 V
5VDD 5.022 V
P_VTT 1.140 V
Vbat 3.312 V

And relevant sysctls:

debug.cpufreq.verbose: 0
debug.cpufreq.lowest: 0
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0
dev.cpufreq.1.%driver: cpufreq
dev.cpufreq.1.%parent: cpu1

dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.temperature: 41.0C
dev.cpu.0.freq: 2000
dev.cpu.0.freq_levels: 3000/35000 2667/28000 2333/22000 2000/16000
dev.cpu.0.cx_supported: C1/0 C2/85
dev.cpu.0.cx_lowest: C2
dev.cpu.0.cx_usage: 49.99% 50.00% last 286us
dev.cpu.1.%desc: ACPI CPU
dev.cpu.1.%driver: cpu
dev.cpu.1.%location: handle=\_PR_.CPU1
dev.cpu.1.%pnpinfo: _HID=none _UID=0
dev.cpu.1.%parent: acpi0
dev.cpu.1.temperature: 41.0C
dev.cpu.1.cx_supported: C1/0 C2/85
dev.cpu.1.cx_lowest: C2
dev.cpu.1.cx_usage: 49.99% 50.00% last 286us

dev.est.0.%desc: Enhanced SpeedStep Frequency Control
dev.est.0.%driver: est
dev.est.0.%parent: cpu0
dev.est.0.freq_settings: 3000/35000 2667/28000 2333/22000 2000/16000
dev.est.1.%desc: Enhanced SpeedStep Frequency Control
dev.est.1.%driver: est
dev.est.1.%parent: cpu1
dev.est.1.freq_settings: 3000/35000 2667/28000 2333/22000 2000/16000

The temperatures you see above are accurate, since it's a system I have
at home where I prefer quiet, low-speed fans. :-)

I should note that the device attachment error (error 6) is something
I've seen on my PDSMi+ boards under RELENG_7 when EIST and C1 Enhanced
Mode were disabled in the BIOS. FreeBSD would report that SpeedStep
existed but that it wasn't able to attach.

I *explicitly* disabled those features in the BIOS since I saw some
bizarre process behaviour ("calcru: runtime went backwards ... for pid
X").

Since upgrading those boxes to RELENG_8, I've been able to re-enable
both BIOS options and use cpufreq(4) with est + powerd without any sign
of what I witnessed on RELENG_7. Of course, I did that only a few days
ago, so it may be too soon to tell.

------------------------------

Message: 9
Date: Sat, 27 Mar 2010 18:53:21 -0700
From: John Long <fb...@sstec.com>
Subject: Re: Powerd and est / eist functionality
To: Ian Smith <smi...@nimnet.asn.au>, Jeremy Chadwick
<fre...@jdc.parodius.com>
Cc: Alexander Motin <m...@freebsd.org>, FreeBSD-STABLE Mailing List
<freebsd...@freebsd.org>
Message-ID: <5.2.1.1.2.201003...@mail.sstec.com>
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 10:35 PM 3/26/2010, Ian Smith wrote:
>On Fri, 26 Mar 2010, Jeremy Chadwick wrote:
>
>[ leaving the MB monitoring stuff alone for your expert attention :-]
>
> > > It jumped up in vcore a little there with powerd. C1E and C2E which
> > > include P-states are what I am really after and I think that the
> > > bios by itself provides those changes better than any other changes
> > > in these settings.
> >
> > ...and this would fall under the est(4) subset driver for cpufreq(4).
>
>Just checking, I know nothing about these so far, but are you suggesting
>that John having C1E and C2E enabled in BIOS may be affecting ACPI/EST
>detection, and that things may be different were these disabled?

No sir. Detection appears to be a function of the signals that are provided
by the mbd regardless of bios settings. As per earlier msgs, I originally
found out that powerd actually increased the TDP of the system at the wall
by about 3 watts. That turning off the bios settings for c1e, c2e and eist
raised the power a little and with powerd it was still higher than with
just bios factors on and no powerd. All the rest is just discovery as to
why this anomaly was so. It seems that ACPI is just not fully functional
for this motherboard and if est does work on other recent mbds then that
would be because of the acpi working better for them as the hard coded est
tables are a bit old. From what I see, est takes tables primary and acpi
fallback. powerd takes est primary and thermal fallback (acpi may be in
there too, forgot now). powerd and thermal is not viable for lowering power
usage at very low cpu rates. It merely provides a phantom crutch until one
does realize it does not truly work, in my case anyway. We need to use the
P-states which lower voltage and true freq, in order to lower tdp
sucessfully, from what I see.

>
>If that's not what you meant, could you expand a little?
>
>John: you may want to explore where this comes together in kern_cpu.c
>where you'll see those cpufreq debugging messages you quoted.

kern_cpu.c looks to be the mech for reading or setting the freq. In there
they mention that using an absolute freq is preferable to the artificial
freq with lengthened clocks because then the voltage is often changed
relative thereto. Where the voltage is changed is my quest. No where in
there nor src/sys/kern do I see a ref for p-states and only in that file is
voltage referenced. Therefore the change in voltage as a function of
frequency must be auto determinant in another place and probably the bios
as my guess so far.

Further looking I see ichss.c in /usr/src/sys/dev/cpufreq (dev not i386
dir) where voltage is referenced. No other refs of votage I notice other
than batt etc and no ref to pstate nor p-state at all in src/sys.
Personally, I deem p-states to be key therefore I may assume that they are
left to lower level bios routines relative to freq unless I am missing
something here. Considering the absolute freq is preferred over the
artificial freq, that is a remnant of powerd (when it falls back to just
thermal), and appears to be a requisite for the lower level routines in
order to change p-states, leads me back to getting est to load proper.
Therefore I should pursue the tables part of its detection, if I continue
digging into things that are over my head..

Some of
>the more gritty documentation may be found browsing with something like:
>% less /sys/{sys,kern,amd64/include}/*cpu*.[ch]

Things that should be left to the pros that have been wading this ocean of
code for years.. :-)

thanks again,

John

>
>cheers, Ian

------------------------------

Message: 10
Date: Sun, 28 Mar 2010 00:16:27 -0700
From: John Long <fb...@sstec.com>
Subject: Re: Powerd and est / eist functionality
To: Jeremy Chadwick <fre...@jdc.parodius.com>
Cc: Alexander Motin <m...@freebsd.org>, FreeBSD-STABLE Mailing List
<freebsd...@freebsd.org>, Ian Smith <smi...@nimnet.asn.au>
Message-ID: <5.2.1.1.2.201003...@mail.sstec.com>
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 05:42 PM 3/27/2010, Jeremy Chadwick wrote:
>On Sat, Mar 27, 2010 at 04:51:49PM -0700, John Long wrote:
>> At 02:14 AM 3/26/2010, Jeremy Chadwick wrote:
>> % dmesg | grep -i smbus
>> pci0: <serial bus, SMBus> at device 31.3 (no driver attached)
>
>All this means is that there's a SMBus-class device sitting on the PCI
>bus which has no driver attached to it. Run "pciconf -lvc" and find the
>device in question, and the output relevant to it.

none1@pci0:0:31:3: class=0x0c0500 card=0x50011458 chip=0x27da8086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = '82801G (ICH7 Family) SMBus Controller'
class = serial bus
subclass = SMBus

put this in
# Intel Core/Core2Duo CPU temperature monitoring driver
device coretemp

# SMBus support, needed for bsdhwmon
device smbus
device smb
device ichsmb

now get this
ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x50011458 chip=0x27da8086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = '82801G (ICH7 Family) SMBus Controller'
class = serial bus
subclass = SMBus

%smbmsg -p
Probing for devices on /dev/smb0:
Device @0x10: w

Does not look to be much there if I am doing this right..

>Given the topic of discussion, I'd say your northbridge is Intel-based,
>which means you need the smb, smbus, and ichsmb drivers loaded. You can
>load these as kernel modules as well. When loading them, do not specify
>the trailing ".ko". See the ichsmb(4) man page for some terse details.
>
>Even if you get a driver attached to the SMBus piece of the northbridge,
>like I said, there's no guarantee there's a H/W monitoring IC that's
>wired to the SMBus. As stated, I don't believe in probing slave
>addresses on the SMBus, so the slave address would have to come from
>Gigabyte, or...
>
>There's a program for Windows (9x/2K/XP/Vista) called SpeedFan which
>does do probing and can/does support SMBus. I have no idea if it works
>on Windows 7 or not:
>
>http://www.almico.com/speedfan.php
>
>If SpeedFan shows you all the data you expect/want, and indicates it's
>talking to a H/W IC over SMBus, then I could add support for your board
>to bsdhwmon (since your motherboard does provide acceptable SMBIOS
>tables for identification). I'd still need to know what slave address
>the chip had, and what exact model of H/W IC it was. SpeedFan might
>provide that.

I have a feeling that my smbus is just not hooked up, nothing there..
speedfan looks cool tho.

>
>It would also help (me at least) if you could reboot your system, go
>into your BIOS and find whatever menu item is associated with Hardware
>Monitoring and write down all of the shown attributes and their values.
>What the BIOS shows is what should be accurate above all else.

>I can point you to numerous present-day motherboards that work just fine
>with cpufreq(4) and est under RELENG_8, and also work when using
>acpi_throttle. Specifically, Supermicro PDSMi+, X7SBA, and X7SBL-L2
>boards. I'm sure there are many others. In all of these are Core2Duo
>or Core2Quad CPUs. An example from the X7SBA system, running powerd:

It looks good, all working..

>
>I should note that the device attachment error (error 6) is something
>I've seen on my PDSMi+ boards under RELENG_7 when EIST and C1 Enhanced
>Mode were disabled in the BIOS. FreeBSD would report that SpeedStep
>existed but that it wasn't able to attach.
>
>I *explicitly* disabled those features in the BIOS since I saw some
>bizarre process behaviour ("calcru: runtime went backwards ... for pid
>X").

Have you tried to measure the wall power with a kill-a-watt yet or can you?
I am curious that things are actually working and tdp goes down when powerd
is running vs not.
About 20.00 - lowes, costco
etc http://www.google.com/search?q=kill-a-watt very handy to check
everything out. My system takes about 15 secs to lower freq to min and the
power goes up a watt each 5 secs or so. Yes, it looks like it is working
but the power meter tells the truth.

John

>--
>| Jeremy Chadwick j...@parodius.com |
>| Parodius Networking http://www.parodius.com/ |
>| UNIX Systems Administrator Mountain View, CA, USA |
>| Making life hard for others since 1977. PGP: 4BD6C0CB |

------------------------------

Message: 11
Date: Sun, 28 Mar 2010 11:16:17 +0000
From: Masoom Shaikh <masoom...@gmail.com>
Subject: Fwd: random FreeBSD panics
To: freebsd...@freebsd.org
Message-ID:
<b10011eb1003280416t539...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

---------- Forwarded message ----------
From: Masoom Shaikh <masoom...@gmail.com>
Date: Sun, Mar 28, 2010 at 8:28 AM
Subject: random FreeBSD panics
To: freebsd...@freebsd.org, freebsd-questions
<freebsd-...@freebsd.org>

Hello List,

I was a happy FreeBSD user, just before I installed FreeBSD8.0-RC1.
Since then, system randomly just freezes, and there is no option other
than hard boot. I guessed this will get solved in 8.0-RELEASE, but it
was not :(

Many times I get vmcore files, not always. I have dumpdev set to AUTO
in my rc.conf. Almost every time it just fsck's the file-system on
reboot. I have not lost any files though. This is a Dell Inspiron 1525
Laptop with 1GB ram, Intel Core2 Duo T5500 with ATI Radeon X1400 card.
The installation in question is KDE4 from ports, with radeon/ati
driver.

I felt the problem is with wpi driver, then suspected dri driver of X.
Then I observed system freezes even if none of this is installed. e.g.
if it is under some load, like building a port and simultaneously
fetching something over network it hangs, and hangs hard. This
persuaded me to think something is wrong in kernel scheduling itself.
May be it is lost in some deadlock, etc... Thus last weekend I thought
I would see how immediate previous version i.e. FreeBSD-7.3-RELEASE
would behave.

I reinstalled FreeBSD7.1 from iso images, svn up'ed FreeBSD7.3 source,
did the normal buildworld, buildkernel, installkernel, installworld
cycle. Unfortunatly this kernel is naughty as well ;-), it also
freezes with same stubbornness. But difference is this time I happen
to catch something interesting.

It panics on NMI, fatal trap 19 while in kernel mode. Loaded the
vmcore file in kgdb and got the backtrace. I obtained vmcore files on
two occasions. I have attached both the back traces. This error most
likely suggests hardware error in RAM, but Windox7 and XP boot just
fine and never caused any errors.

To verify if I have errors in my RAM I let run sysutils/memtest86+
overnight, to double verify I also executed Windows Memory Diagnostic
test for four times. None of them reported errors. Can anyone here
suggest any solution.

Masoom Shaikh

forwarding to stable@ with respect to a generous suggestion
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vmcore0.log
Type: application/octet-stream
Size: 3304 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100328/55ce1135/vmcore0-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vmcore1.log
Type: application/octet-stream
Size: 3346 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100328/55ce1135/vmcore1-0001.obj

------------------------------

Message: 12
Date: Sun, 28 Mar 2010 13:19:59 +0300
From: "Ronald Klop" <ronald-...@klop.yi.org>
Subject: Re: NFS lockd problem
To: "Giulio Ferro" <au...@zirakzigil.org>, "Chuck Swiger"
<csw...@mac.com>
Cc: "freeb...@freebsd.org" <freeb...@freebsd.org>,
freebsd...@freebsd.org
Message-ID: <op.u99y3lgt8527sy@pinky>
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes

On Sat, 27 Mar 2010 20:50:17 +0200, Chuck Swiger <csw...@mac.com> wrote:

> On Mar 26, 2010, at 3:08 AM, Giulio Ferro wrote:
>> Outset:
>> 1 NFS server (with lockd)
>> 2 NFS client (with lockd)
>>
>> The clients serve several jails with apache, whose data (www) resides
>> on the server
>
> If you need file locking to work reliably, you pretty much have to give
> up on using NFS + rpc.lockd and run against a local UFS filesystem.

I don't have this experience. I use NFS locking between FreeBSD, Linux,
NetApp and SUN stuff. Older versions of FreeBSD had some troubles, but
more recent ones work very well.

Ronald.

------------------------------

Message: 13
Date: Sun, 28 Mar 2010 13:24:23 +0300
From: "Ronald Klop" <ronald-...@klop.yi.org>
Subject: Re: NFS lockd problem
To: "freeb...@freebsd.org" <freeb...@freebsd.org>,
freebsd...@freebsd.org, "Giulio Ferro" <au...@zirakzigil.org>
Message-ID: <op.u99zaxmh8527sy@pinky>
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes

On Fri, 26 Mar 2010 12:08:26 +0200, Giulio Ferro <au...@zirakzigil.org>
wrote:

> Outset:
> 1 NFS server (with lockd)
> 2 NFS client (with lockd)
>
> The clients serve several jails with apache, whose data (www) resides on
> the server
>
> From time to time everything seem to freeze. Then, after one minute or
> so, the system
> works again as nothing had happened.
>
> In these occasions I get this in the logs on the client madchines:
> Mar 26 10:29:38 virt1 kernel: nfs server
> 192.168.40.121:/data/mount_servers/wwwsec/www: lockd not responding
>
> followed shortly after by:
>
> Mar 26 10:29:38 virt1 kernel: nfs server
> 192.168.40.121:/data/mount_servers/wwwsec/www: lockd is alive again
>
>
> On the server I only get this:
> Mar 26 10:29:31 data1 kernel: NLM: failed to contact remote rpcbind,
> stat = 5, port = 28416
>
> I don't think it's a network problem, since all connections are local
> and high speed (1Gb/s)
>
> I must admit that, with the other nfs problem I reported weeks ago, this
> kind of freebsd system seems
> less than stable to me, and this is very disappointing...
>
> Anyway I'd appreciate any pointer on this issue...

I'm no NFS expert, so I don't know if I can help, but regularly people
want to know your FreeBSD version(s), your used NFS version, if you are
running NFS over TCP or UDP. Does it help to switch between UDP/TCP?

Ronald.

------------------------------

End of freebsd-stable Digest, Vol 349, Issue 8
**********************************************

0 new messages