Re: [ZFS] Server periodically become unavailable
On 20.10.2012 15:11, Vladislav Prodan wrote: FreeBSD 9.1-PRERELEASE #0: Wed Jul 25 01:40:56 EEST 2012 I have the server: 8 cores AMD, 16GB RAM, 4x3TB HDD in RAID10 for ZFS. Sometime wheels fall off the server and the network. Can this clean-up memory for ZFS cache? I enclose a picture with the monitoring system at the time lags. http://imageshack.us/a/img341/9643/memoryusage.png http://imageshack.us/a/img22/6935/nginxclientstat.png http://imageshack.us/a/img19/8817/realmemory.png #cat /etc/sysctl.conf kern.ipc.somaxconn=65535 Remove this. It doesn't do what you think it does. kern.ipc.maxsockets=204800 net.inet.ip.portrange.first=1024 net.inet.ip.portrange.last=65535 kern.ipc.shmmax=67108864 kern.ipc.shmall=67108864 net.inet.tcp.rfc3465=0 Any particular reason why you turn this off? net.graph.maxdgram=8388608 net.graph.recvspace=8388608 net.route.netisr_maxqlen=4096 kern.ipc.nmbclusters=40 kern.ipc.maxsockbuf=83886080 83MB for a socket buffer is too much unless you're doing some HPC stuff. The default should be fine. net.inet.tcp.recvbuf_inc=524288 Again, this should be left at default unless you have a very specific reason to increment it. net.inet.tcp.recvbuf_max=16777216 ditto. net.inet.tcp.sendbuf_inc=524288 ditto. net.inet.tcp.sendbuf_max=16777216 ditto. net.inet.tcp.sendspace=65536 This is the default setting. net.inet.tcp.keepidle=30 net.inet.tcp.keepintvl=6 net.inet.ip.fw.dyn_max=65535 net.inet.ip.fw.dyn_buckets=65536 net.inet.ip.fw.dyn_ack_lifetime=120 net.inet.ip.fw.dyn_syn_lifetime=10 net.inet.tcp.nolocaltimewait=1 security.bsd.hardlink_check_uid=1 security.bsd.hardlink_check_gid=1 security.bsd.see_other_uids=0 security.bsd.see_other_gids=0 -- Andre ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problem reading vitals from Gigabyte H77-DH3H
Hello Jeremy, Monday, October 22, 2012, 6:03:49 AM, you wrote: > I'm not subscribed to the FreeBSD lists any longer, but I did come > across this thread via the web: > http://lists.freebsd.org/pipermail/freebsd-stable/2012-October/070169.html > Either (or both) of you are free to bounce a copy of my Email here to > the list if you feel it'd benefit others. > I have a lot of familiarity with hardware monitoring chips and > interfacing with them (as the author of ports/sysutils/bsdhwmon). > The H/W monitoring chip on that Gigabyte motherboard is **not** the same > or has resistors/pullups that differ from what the OpenBSD sensors > framework code expects. That is quite evident from the below. There > are also very likely labels that are wrong. I'll get to explaining how > to fix that properly further down. > Let me explain in detail one section at a time: >> hw.sensors.it0.volt0: 1,42 VDC (VCORE_A) >> hw.sensors.it0.volt1: 2,72 VDC (VCORE_B) > The term "Vcore" refers to the CPU core voltage. This is a > per-physical-CPU basis. This software is assuming there's 2 physical > CPUs (not cores, I'm talking about physical processors). > VCORE_A may be correct (meaning 1.42V), however it depends on the CPU > model. Derek did not disclose this so I cannot tell you if 1.42V is > considered "correct" or not. Some models run at 1.2V, others 1.5V, > others vary. It is i5-3470 3.2GHz quad core (The entire component list I used to build is here: http://pcpartpicker.com/p/koz3). The CPU is not overclocked, I set "auto" for all this kind of settings in the BIOS. > VCORE_B is probably not VCORE_B at all. However, worse: 2.72V does not > look to be a correct/valid voltage no matter what (even if for an MCH or > a southbridge). So probably a calculation error or its reading the > wrong bits from the chip. >> hw.sensors.it0.volt2: 2,70 VDC (+3.3V) > This is also wrong -- either the voltage or the label. There is no way > your system would be stable if a +3.3V line was at +2.7V. So another > calculation error or reading wrong bits from the chip. >> hw.sensors.it0.volt3: 4,60 VDC (+5V) > This is probably also wrong, but it's hard to say. +5V is relied on > heavily throughout the entire system, so a 0.4V drop is pretty damn > major. So probably another calculation error or reading wrong bits from > the chip. >> hw.sensors.it0.volt4: 0,06 VDC (+12V) > This is flat out completely wrong on numerous levels. >> hw.sensors.it0.volt5: -5,08 VDC (Unused) > No idea. This could be -5V monitoring, but it depends. Only Gigabyte > would know. >> hw.sensors.it0.volt6: -6,53 VDC (-12V) > Also totally wrong (voltage and label). So another calculation error or > reading wrong bits from the chip. >> hw.sensors.it0.volt7: 3,74 VDC (+5VSB) > Also totally wrong (voltage and/or label). "+5Vsb" stands for "+5V > standby"; it's the +5V line that comes off the PSU and is *always on*, > even when the motherboard is off. It's what allows systems to power > back up from sleep state. So another calculation error or reading wrong > bits from the chip. >> hw.sensors.it0.volt8: 2,14 VDC (VBAT) > Also totally wrong (voltage and/or label). "VBAT" refers to the voltage > of the CMOS battery, which should be +3.3V. So another calculation > error or reading wrong bits from the chip. > Here is what proper labels and a proper system should show, as an > example: > # bsdhwmon > CPU1 Temperature 31 C > System Temperature 35 C > FAN10 RPM > FAN20 RPM > FAN30 RPM > FAN4 2042 RPM > FAN50 RPM > FAN6 1875 RPM > VcoreA 1.106 V > MCH Core1.522 V > -12V -12.288 V > V_DIMM 1.712 V > +3.3V 3.392 V > +12V 12.096 V > 5Vsb5.070 V > 5VDD5.118 V > P_VTT 1.142 V > Vbat3.328 V > The bottom line here is this: the problem with the sensors framework is > that it has no concept of per-motherboard engineering (to my knowledge). > Again, that is why I designed bsdhwmon the way I did -- I key off of > SMBIOS string data because it's the only way to do things as reliable as > possible. Each motherboard model requires unique support. Without > that, voltage calculations are either wrong, or labels are completely > wrong, or both. > If I could get within the bowels of Gigabyte and actually talk to a > **real engineer** and not tech support, I could find out if their > GA-H77-DS3H motherboard has SMBus tie-ins for their H/W monitoring chip. > If it does, I **absolutely** could add PROPER support for it to > bsdhwmon. > However, regardless of that, it also requires the owner of the > motherboard to be able to run the monitoring software provided by the > vendor for the board (usually Windows software) as a "baseline"
Re: ${CTFCONVERT_CMD} expands to empty string
On Sunday, October 21, 2012 8:25:32 pm Andrey Chernov wrote:
> Those lines cause this error:
> .if ${MK_CTF} != "no"
> CTFCONVERT_CMD= ${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
> .elif ${MAKE_VERSION} >= 520300
> CTFCONVERT_CMD=
> .else
> CTFCONVERT_CMD= @:
> .endif
>
> My make version is 9201206140
> So, either the check for >= 520300 is incorrect or change for empty
> make variables expansion is not merged into stable-9
I can't reproduce this doing a buildworld of a stable/9 checkout on a 9.0-
stable machine btw. What exact contents of /etc/src.conf and commands are you
using to reproduce this?
I also can't find the string "empty string" in the output of my stable/9
'make universe' build before I committed this.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ${CTFCONVERT_CMD} expands to empty string
On 22.10.2012 19:42, John Baldwin wrote:
> On Sunday, October 21, 2012 8:25:32 pm Andrey Chernov wrote:
>> Those lines cause this error:
>> .if ${MK_CTF} != "no"
>> CTFCONVERT_CMD= ${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
>> .elif ${MAKE_VERSION} >= 520300
>> CTFCONVERT_CMD=
>> .else
>> CTFCONVERT_CMD= @:
>> .endif
>>
>> My make version is 9201206140
>> So, either the check for >= 520300 is incorrect or change for empty
>> make variables expansion is not merged into stable-9
>
> I can't reproduce this doing a buildworld of a stable/9 checkout on a 9.0-
> stable machine btw. What exact contents of /etc/src.conf and commands are
> you
> using to reproduce this?
>
> I also can't find the string "empty string" in the output of my stable/9
> 'make universe' build before I committed this.
>
/etc/src.conf:
WITHOUT_AMD=yes
WITHOUT_APM=yes
WITHOUT_ATM=yes
WITHOUT_AUDIT=yes
WITH_BSD_GREP=yes
WITHOUT_BLUETOOTH=yes
WITHOUT_BSNMP=yes
WITHOUT_CDDL=yes
WITHOUT_CLANG=yes
WITHOUT_CTM=yes
WITHOUT_FORTRAN=yes
WITHOUT_GPIB=yes
WITHOUT_GPIO=yes
WITHOUT_GSSAPI=yes
WITHOUT_I4B=yes
WITH_IDEA=yes
WITHOUT_IPFILTER=yes
WITHOUT_IPX=yes
WITHOUT_NCP=yes
WITHOUT_NIS=yes
WITHOUT_KERBEROS=yes
WITHOUT_MAILWRAPPER=yes
WITHOUT_PF=yes
WITHOUT_PMC=yes
WITHOUT_PROFILE=yes
WITHOUT_RCMDS=yes
WITHOUT_SLIP=yes
WITHOUT_WIRELESS=yes
I got that useless line _each_ .c file compiles. Example commands:
cd /usr/src/usr.bin/make
make clean
make
I got:
cc -O2 -pipe -march=pentium4 -I/usr/src/usr.bin/make
-DMAKE_VERSION=\"9201206140\" -DDEFSHELLNAME=\"sh\" -std=gnu99
-fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch
-Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline
-Wnested-externs -Wredundant-decls -Wold-style-definition
-Wno-pointer-sign -c /usr/src/usr.bin/make/arch.c
${CTFCONVERT_CMD} expands to empty string
...etc... on each file.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problem reading vitals from Gigabyte H77-DH3H
On Mon, Oct 22, 2012 at 08:38:11AM -0700, Derek Kulinski wrote:
> Hello Jeremy,
>
> Monday, October 22, 2012, 6:03:49 AM, you wrote:
>
{snipping}
> > Let me explain in detail one section at a time:
>
> >> hw.sensors.it0.volt0: 1,42 VDC (VCORE_A)
> >> hw.sensors.it0.volt1: 2,72 VDC (VCORE_B)
>
> > The term "Vcore" refers to the CPU core voltage. This is a
> > per-physical-CPU basis. This software is assuming there's 2 physical
> > CPUs (not cores, I'm talking about physical processors).
>
> > VCORE_A may be correct (meaning 1.42V), however it depends on the CPU
> > model. Derek did not disclose this so I cannot tell you if 1.42V is
> > considered "correct" or not. Some models run at 1.2V, others 1.5V,
> > others vary.
>
> It is i5-3470 3.2GHz quad core (The entire component list I used to
> build is here: http://pcpartpicker.com/p/koz3).
> The CPU is not overclocked, I set "auto" for all this kind of settings
> in the BIOS.
Then it's simple: the voltage shown is wrong. The Core i5-3470 runs at
a stock Vcore of 1.1V, and with some CPU features will downthrottle to
around 1.0V. Thus, 1.42V is too high (thus wrong), and is just further
indication that the calculation is wrong or the data being obtained is
wrong. If your CPU was really running at 1.42V, it'd have crashed by
the time you got into the BIOS. (The highest I've seen people overclock
Vcore on this chip is 1.25V, so 1.42V is obviously a calculation error)
{snipping}
> > If I could get within the bowels of Gigabyte and actually talk to a
> > **real engineer** and not tech support, I could find out if their
> > GA-H77-DS3H motherboard has SMBus tie-ins for their H/W monitoring chip.
> > If it does, I **absolutely** could add PROPER support for it to
> > bsdhwmon.
>
> > However, regardless of that, it also requires the owner of the
> > motherboard to be able to run the monitoring software provided by the
> > vendor for the board (usually Windows software) as a "baseline"
> > comparison -- or -- take a screenshot of the hardware monitoring details
> > in the BIOS (or UEFI system) for comparison. Sometimes a VERY HIGH
> > RESOLUTION photo of the motherboard is helpful -- though sometimes this
> > isn't useful because motherboard vendors actually use "emulation modes"
> > of their Super I/O chips (e.g. Chip Z is installed on the board, but
> > it's configured to emulate Chip X which the Chip company made 2 years
> > ago). I've found this on many Supermicro boards actually -- what's
> > silkscreened on the chips says one thing but how the chip *behaves* is
> > another.
>
> Not exactly a screenshot but I wrote down values given by BIOS:
> CPU Vcore1.044V
> DRAM Voltage 1.524V
> +3.3V3.363V
> +12V 12.168V
> CPU Temp 33C
> System Temp 30C
And here we have proof that the sensor data you're seeing in FreeBSD is
wrong, so I rest my case.
> Please let me know if this is enough.
I'll repeat what I wrote:
If I could get within the bowels of Gigabyte and actually talk to a
**real engineer** and not tech support, I could find out if their
GA-H77-DS3H motherboard has SMBus tie-ins for their H/W monitoring chip.
If it does, I **absolutely** could add PROPER support for it to
bsdhwmon.
> As for the picture of the motherboard, this one
> (http://www.nix.ru/autocatalog/motherboards_gigabyte/135869_2245_draft.jpg)
> looks way better than any of my picture.
The H/W monitoring and Super I/O chip on this board is from iTE, but I
cannot read the silkscreening. The chip model matters.
But furthermore, as I said above, the silkscreening is not always an
indicator of how the chip operates.
The official site only says "iTE I/O Controller", which is also too
vague.
This is why getting full documentation from the board vendor is needed.
Getting this is like pulling teeth. Given that Gigabyte is a
workstation and consumer-focused company (not server-focused), the
likelihood of them understanding this question is very low:
"Hello. I am a developer of H/W monitoring software for FreeBSD, and
I'm looking to get technical documentation about the H/W monitoring and
Super I/O chip used on the Gigabyte GA-H77-DS3H (revision 1.0)
motherboard. I need to know what chip is used that provides voltages,
fan RPMs, and temperatures, and I need to know if that chip has SMBus
tie-ins. If it does, I need to know what the SMBus slave address is,
and what the register offsets are + full descriptions of the registers.
If you have calculation formulas (for in-line resistor offsets and so
on) that would be quite helpful. Thank you."
Supermicro Technical Support, comparatively, understands the above
question and will give full documentation for each board you ask for.
I've asked them for 10-12 boards "in bulk" once, and they provided all
the documentation for every board. It takes them about 2 weeks to get
it to you -- because they have to get it from an actual engineer. But
getting this from consumer-focused manufacturers (ex. Asus, Gigabyte,
Re: ${CTFCONVERT_CMD} expands to empty string
And simple test case proving that make v9201206140 dislike empty commands.
Makefile:
CTFCONVERT_CMD=
all:
echo ${MAKE_VERSION}
${CTFCONVERT_CMD}
echo b
> make
echo 9201206140
9201206140
${CTFCONVERT_CMD} expands to empty string
echo b
b
On 22.10.2012 20:08, Andrey Chernov wrote:
> On 22.10.2012 19:42, John Baldwin wrote:
>> On Sunday, October 21, 2012 8:25:32 pm Andrey Chernov wrote:
>>> Those lines cause this error:
>>> .if ${MK_CTF} != "no"
>>> CTFCONVERT_CMD= ${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
>>> .elif ${MAKE_VERSION} >= 520300
>>> CTFCONVERT_CMD=
>>> .else
>>> CTFCONVERT_CMD= @:
>>> .endif
>>>
>>> My make version is 9201206140
>>> So, either the check for >= 520300 is incorrect or change for empty
>>> make variables expansion is not merged into stable-9
>>
>> I can't reproduce this doing a buildworld of a stable/9 checkout on a 9.0-
>> stable machine btw. What exact contents of /etc/src.conf and commands are
>> you
>> using to reproduce this?
>>
>> I also can't find the string "empty string" in the output of my stable/9
>> 'make universe' build before I committed this.
>>
>
> /etc/src.conf:
> WITHOUT_AMD=yes
> WITHOUT_APM=yes
> WITHOUT_ATM=yes
> WITHOUT_AUDIT=yes
> WITH_BSD_GREP=yes
> WITHOUT_BLUETOOTH=yes
> WITHOUT_BSNMP=yes
> WITHOUT_CDDL=yes
> WITHOUT_CLANG=yes
> WITHOUT_CTM=yes
> WITHOUT_FORTRAN=yes
> WITHOUT_GPIB=yes
> WITHOUT_GPIO=yes
> WITHOUT_GSSAPI=yes
> WITHOUT_I4B=yes
> WITH_IDEA=yes
> WITHOUT_IPFILTER=yes
> WITHOUT_IPX=yes
> WITHOUT_NCP=yes
> WITHOUT_NIS=yes
> WITHOUT_KERBEROS=yes
> WITHOUT_MAILWRAPPER=yes
> WITHOUT_PF=yes
> WITHOUT_PMC=yes
> WITHOUT_PROFILE=yes
> WITHOUT_RCMDS=yes
> WITHOUT_SLIP=yes
> WITHOUT_WIRELESS=yes
>
> I got that useless line _each_ .c file compiles. Example commands:
> cd /usr/src/usr.bin/make
> make clean
> make
> I got:
> cc -O2 -pipe -march=pentium4 -I/usr/src/usr.bin/make
> -DMAKE_VERSION=\"9201206140\" -DDEFSHELLNAME=\"sh\" -std=gnu99
> -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W
> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch
> -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline
> -Wnested-externs -Wredundant-decls -Wold-style-definition
> -Wno-pointer-sign -c /usr/src/usr.bin/make/arch.c
> ${CTFCONVERT_CMD} expands to empty string
> ...etc... on each file.
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ${CTFCONVERT_CMD} expands to empty string
All that happens because this commit is not merged into stable-9.
Do you plan to mere it by yourself?
r228157 | fjoe | 2011-11-30 22:07:38 +0400 (ср, 30 ноя 2011) | 10 lines
- Fix segmentation fault when running "+command" when run with -jX -n due
to Compat_RunCommand() being called with `cmd' that is not on the node->commands
list
- Make ellipsis ("..." command) handling consistent: check for "..." command
in job make after variables expansion to match compat make behavior
- Fix empty command handling (after variables expansion and @+- modifiers
are processed): now empty commands are ignored in compat make and are not
printed in job make case
- Bump MAKE_VERSION to 5-2011-11-30-0
On 22.10.2012 20:45, Andrey Chernov wrote:
> And simple test case proving that make v9201206140 dislike empty commands.
> Makefile:
>
> CTFCONVERT_CMD=
> all:
> echo ${MAKE_VERSION}
> ${CTFCONVERT_CMD}
> echo b
>
>> make
> echo 9201206140
> 9201206140
> ${CTFCONVERT_CMD} expands to empty string
> echo b
> b
>
> On 22.10.2012 20:08, Andrey Chernov wrote:
>> On 22.10.2012 19:42, John Baldwin wrote:
>>> On Sunday, October 21, 2012 8:25:32 pm Andrey Chernov wrote:
Those lines cause this error:
.if ${MK_CTF} != "no"
CTFCONVERT_CMD= ${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
.elif ${MAKE_VERSION} >= 520300
CTFCONVERT_CMD=
.else
CTFCONVERT_CMD= @:
.endif
My make version is 9201206140
So, either the check for >= 520300 is incorrect or change for empty
make variables expansion is not merged into stable-9
>>>
>>> I can't reproduce this doing a buildworld of a stable/9 checkout on a 9.0-
>>> stable machine btw. What exact contents of /etc/src.conf and commands are
>>> you
>>> using to reproduce this?
>>>
>>> I also can't find the string "empty string" in the output of my stable/9
>>> 'make universe' build before I committed this.
>>>
>>
>> /etc/src.conf:
>> WITHOUT_AMD=yes
>> WITHOUT_APM=yes
>> WITHOUT_ATM=yes
>> WITHOUT_AUDIT=yes
>> WITH_BSD_GREP=yes
>> WITHOUT_BLUETOOTH=yes
>> WITHOUT_BSNMP=yes
>> WITHOUT_CDDL=yes
>> WITHOUT_CLANG=yes
>> WITHOUT_CTM=yes
>> WITHOUT_FORTRAN=yes
>> WITHOUT_GPIB=yes
>> WITHOUT_GPIO=yes
>> WITHOUT_GSSAPI=yes
>> WITHOUT_I4B=yes
>> WITH_IDEA=yes
>> WITHOUT_IPFILTER=yes
>> WITHOUT_IPX=yes
>> WITHOUT_NCP=yes
>> WITHOUT_NIS=yes
>> WITHOUT_KERBEROS=yes
>> WITHOUT_MAILWRAPPER=yes
>> WITHOUT_PF=yes
>> WITHOUT_PMC=yes
>> WITHOUT_PROFILE=yes
>> WITHOUT_RCMDS=yes
>> WITHOUT_SLIP=yes
>> WITHOUT_WIRELESS=yes
>>
>> I got that useless line _each_ .c file compiles. Example commands:
>> cd /usr/src/usr.bin/make
>> make clean
>> make
>> I got:
>> cc -O2 -pipe -march=pentium4 -I/usr/src/usr.bin/make
>> -DMAKE_VERSION=\"9201206140\" -DDEFSHELLNAME=\"sh\" -std=gnu99
>> -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W
>> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
>> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch
>> -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline
>> -Wnested-externs -Wredundant-decls -Wold-style-definition
>> -Wno-pointer-sign -c /usr/src/usr.bin/make/arch.c
>> ${CTFCONVERT_CMD} expands to empty string
>> ...etc... on each file.
>>
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD in Google Code-In 2012? You can help too!
On Tue, Oct 16, 2012 at 10:19:57AM +, Wojciech A. Koszek wrote: > (cross-posted message; please keep discussion on freebsd-hackers@) > > Hello, > > Last year FreeBSD qualified for Google Code-In 2011 event--contest for > youngest open-source hackers in 13-17yr age range: > > http://www.google-melange.com/gci/homepage/google/gci2012 > > It was successful. We gained one more FreeBSD developer thanks to that > (Isabell Long) We're pondering participating in the contest this year as > well. > > For now we only have 25 ideas. We need at least 100. > > I felt all members of the FreeBSD community should help, so please submit > your own Google Code-In 2012 ideas here: > > http://www.emailmeform.com/builder/form/4aU93Obxo4NYdVAgb1 > > Examples of previously completed tasks: > > http://wiki.freebsd.org/GoogleCodeIn/2011Tasks > > Those of you who have Wiki access, please spent 2 more minutes and submit > straight to Wiki: > > http://wiki.freebsd.org/GoogleCodeIn/2012Tasks > > I plan to send out next e-mail if there's any progress on this project. > > Help will be appreciated. > Update: It looks pretty bad so far. Page: http://wiki.freebsd.org/GoogleCodeIn/2012Tasks Has 38 tasks so far out of which: ~30 would qualify. Consider this e-mail to be the last call for action. Otherwise we'll have to pull back and concentrate our efforts on GSOC instead. -- Wojciech A. Koszek wkos...@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ${CTFCONVERT_CMD} expands to empty string
On Monday, October 22, 2012 1:01:53 pm Andrey Chernov wrote:
> All that happens because this commit is not merged into stable-9.
> Do you plan to mere it by yourself?
>
> r228157 | fjoe | 2011-11-30 22:07:38 +0400 (ср, 30 ноя 2011) | 10 lines
>
> - Fix segmentation fault when running "+command" when run with -jX -n due
> to Compat_RunCommand() being called with `cmd' that is not on the node-
>commands
> list
> - Make ellipsis ("..." command) handling consistent: check for "..." command
> in job make after variables expansion to match compat make behavior
> - Fix empty command handling (after variables expansion and @+- modifiers
> are processed): now empty commands are ignored in compat make and are not
> printed in job make case
> - Bump MAKE_VERSION to 5-2011-11-30-0
As soon as I can reproduce something that tests it, sure (I want to have a
test case I can reproduce so that I can also check for 8). Your test
Makefile does break on 8 and 9, want to do some more tests.
> On 22.10.2012 20:45, Andrey Chernov wrote:
> > And simple test case proving that make v9201206140 dislike empty commands.
> > Makefile:
> >
> > CTFCONVERT_CMD=
> > all:
> > echo ${MAKE_VERSION}
> > ${CTFCONVERT_CMD}
> > echo b
> >
> >> make
> > echo 9201206140
> > 9201206140
> > ${CTFCONVERT_CMD} expands to empty string
> > echo b
> > b
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD in Google Code-In 2012? You can help too!
That wiki site has a distinct lack of help about: * what is required from us; * what the target is (kids, right?) * some examples of good and bad projects. Right now I have absolutely no idea what would constitute a good or bad coding project. :/ adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
kldload if_igb twice needed to bring nic into operation
Hello, when using igb as module, no packet is received. If I send out anything, I see the packet with tcpdump, also the switch learns the MAC address, but nothing comes back in - total silenc, no boradcasts, nothing. If I unload the module and load it again, everything works as expected! No matter if I load it by 4th loader, or later, I always have tio unload first then load it again. I'ts late here, I'll see tomorrow if things change when compieled into kernel. Maby somebody has an idea what the source of the problem could be. Please find atteched some info, the OS is 9-RC2-amd64 on ESXi5.1 and nics are pci-passthrough. dmesg from first kldload: igb0: port 0x6000-0x601f mem 0xd662-0xd663,0xd680-0xd6bf,0xd660-0xd6603fff irq 16 at device 0.0 on pci5 igb0: Using MSIX interrupts with 3 vectors igb0: Ethernet address: 90:e2:ba:18:f8:85 igb0: Bound queue 0 to cpu 0 igb0: Bound queue 1 to cpu 1 igb1: port 0x7000-0x701f mem 0xd6c2-0xd6c3,0xd700-0xd73f,0xd6c0-0xd6c03fff irq 17 at device 0.0 on pci6 igb1: Using MSIX interrupts with 3 vectors igb1: Ethernet address: 90:e2:ba:28:0a:47 igb1: Bound queue 0 to cpu 2 igb1: Bound queue 1 to cpu 3 igb0: link state changed to UP tcpdump -n -i igb0 -> absolute silence.. After some attemtions to connect to this host, sysctl dev.igb.0: dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 2.3.4 dev.igb.0.%driver: igb dev.igb.0.%location: slot=0 function=0 handle=\_SB_.PCI0.PE60.S1F0 dev.igb.0.%pnpinfo: vendor=0x8086 device=0x10c9 subvendor=0x8086 subdevice=0xa03c class=0x02 dev.igb.0.%parent: pci5 dev.igb.0.nvm: -1 dev.igb.0.enable_aim: 1 dev.igb.0.fc: 3 dev.igb.0.rx_processing_limit: 100 dev.igb.0.link_irq: 0 dev.igb.0.dropped: 0 dev.igb.0.tx_dma_fail: 0 dev.igb.0.rx_overruns: 0 dev.igb.0.watchdog_timeouts: 0 dev.igb.0.device_control: 1488978497 dev.igb.0.rx_control: 67272738 dev.igb.0.interrupt_mask: 4 dev.igb.0.extended_int_mask: 2147483648 dev.igb.0.tx_buf_alloc: 0 dev.igb.0.rx_buf_alloc: 0 dev.igb.0.fc_high_water: 47488 dev.igb.0.fc_low_water: 47472 dev.igb.0.queue0.no_desc_avail: 0 dev.igb.0.queue0.tx_packets: 1 dev.igb.0.queue0.rx_packets: 0 dev.igb.0.queue0.rx_bytes: 0 dev.igb.0.queue0.lro_queued: 0 dev.igb.0.queue0.lro_flushed: 0 dev.igb.0.queue1.no_desc_avail: 0 dev.igb.0.queue1.tx_packets: 0 dev.igb.0.queue1.rx_packets: 0 dev.igb.0.queue1.rx_bytes: 0 dev.igb.0.queue1.lro_queued: 0 dev.igb.0.queue1.lro_flushed: 0 dev.igb.0.mac_stats.excess_coll: 0 dev.igb.0.mac_stats.single_coll: 0 dev.igb.0.mac_stats.multiple_coll: 0 dev.igb.0.mac_stats.late_coll: 0 dev.igb.0.mac_stats.collision_count: 0 dev.igb.0.mac_stats.symbol_errors: 0 dev.igb.0.mac_stats.sequence_errors: 0 dev.igb.0.mac_stats.defer_count: 0 dev.igb.0.mac_stats.missed_packets: 0 dev.igb.0.mac_stats.recv_no_buff: 0 dev.igb.0.mac_stats.recv_undersize: 0 dev.igb.0.mac_stats.recv_fragmented: 0 dev.igb.0.mac_stats.recv_oversize: 0 dev.igb.0.mac_stats.recv_jabber: 0 dev.igb.0.mac_stats.recv_errs: 0 dev.igb.0.mac_stats.crc_errs: 0 dev.igb.0.mac_stats.alignment_errs: 0 dev.igb.0.mac_stats.coll_ext_errs: 0 dev.igb.0.mac_stats.xon_recvd: 0 dev.igb.0.mac_stats.xon_txd: 0 dev.igb.0.mac_stats.xoff_recvd: 0 dev.igb.0.mac_stats.xoff_txd: 0 dev.igb.0.mac_stats.total_pkts_recvd: 122 dev.igb.0.mac_stats.good_pkts_recvd: 20 dev.igb.0.mac_stats.bcast_pkts_recvd: 6 dev.igb.0.mac_stats.mcast_pkts_recvd: 9 dev.igb.0.mac_stats.rx_frames_64: 8 dev.igb.0.mac_stats.rx_frames_65_127: 10 dev.igb.0.mac_stats.rx_frames_128_255: 1 dev.igb.0.mac_stats.rx_frames_256_511: 1 dev.igb.0.mac_stats.rx_frames_512_1023: 0 dev.igb.0.mac_stats.rx_frames_1024_1522: 0 dev.igb.0.mac_stats.good_octets_recvd: 1878 dev.igb.0.mac_stats.good_octets_txd: 64 dev.igb.0.mac_stats.total_pkts_txd: 1 dev.igb.0.mac_stats.good_pkts_txd: 1 dev.igb.0.mac_stats.bcast_pkts_txd: 1 dev.igb.0.mac_stats.mcast_pkts_txd: 0 dev.igb.0.mac_stats.tx_frames_64: 1 dev.igb.0.mac_stats.tx_frames_65_127: 0 dev.igb.0.mac_stats.tx_frames_128_255: 0 dev.igb.0.mac_stats.tx_frames_256_511: 0 dev.igb.0.mac_stats.tx_frames_512_1023: 0 dev.igb.0.mac_stats.tx_frames_1024_1522: 0 dev.igb.0.mac_stats.tso_txd: 0 dev.igb.0.mac_stats.tso_ctx_fail: 0 dev.igb.0.interrupts.asserts: 239 dev.igb.0.interrupts.rx_pkt_timer: 20 dev.igb.0.interrupts.rx_abs_timer: 0 dev.igb.0.interrupts.tx_pkt_timer: 0 dev.igb.0.interrupts.tx_abs_timer: 20 dev.igb.0.interrupts.tx_queue_empty: 1 dev.igb.0.interrupts.tx_queue_min_thresh: 0 dev.igb.0.interrupts.rx_desc_min_thresh: 0 dev.igb.0.interrupts.rx_overrun: 0 dev.igb.0.host.breaker_tx_pkt: 0 dev.igb.0.host.host_tx_pkt_discard: 0 dev.igb.0.host.rx_pkt: 0 dev.igb.0.host.breaker_rx_pkts: 0 dev.igb.0.host.breaker_rx_pkt_drop: 0 dev.igb.0.host.tx_good_pkt: 0 dev.igb.0.host.breaker_tx_pkt_drop: 0 dev.igb.0.host.rx_good_bytes: 1878 dev.igb.0.host.tx_good_bytes: 64 dev.igb.0.host.length_errors: 0 dev.igb.0.host.serdes_violation_pkt: 0 dev.igb.0.host.header_redir_missed: 0 --- dmesg from unloading if_igb and
Re: kldload if_igb twice needed to bring nic into operation
schrieb Harald Schmalzbauer am 22.10.2012 21:33 (localtime): > Hello, > > when using igb as module, no packet is received. > If I send out anything, I see the packet with tcpdump, also the switch > learns the MAC address, but nothing comes back in - total silenc, no > boradcasts, nothing. > If I unload the module and load it again, everything works as expected! > No matter if I load it by 4th loader, or later, I always have tio unload > first then load it again. > I'ts late here, I'll see tomorrow if things change when compieled into > kernel. > Maby somebody has an idea what the source of the problem could be. > Please find atteched some info, the OS is 9-RC2-amd64 on ESXi5.1 and > nics are pci-passthrough. I found one possibly relevant difference: Non-Working state:dev.igb.0.link_irq: 0 Working state: dev.igb.0.link_irq: 2 Seems to be reproducable. If I power up the machine and load if_igb for the first time, dev.igb.0.link_irq is always "0" and after unloading and loading again, it's always "2". And tcpdump only captures anything when dev.igb.0.link_irq=2. That's also true for reboot. When I don't power off the machine, just rebooting, packets are passing right from the first kldload!!! Here's the complete dev.igb sysctl after second kldload: dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 2.3.4 dev.igb.0.%driver: igb dev.igb.0.%location: slot=0 function=0 handle=\_SB_.PCI0.PE60.S1F0 dev.igb.0.%pnpinfo: vendor=0x8086 device=0x10c9 subvendor=0x8086 subdevice=0xa03c class=0x02 dev.igb.0.%parent: pci5 dev.igb.0.nvm: -1 dev.igb.0.enable_aim: 1 dev.igb.0.fc: 3 dev.igb.0.rx_processing_limit: 100 dev.igb.0.link_irq: 2 dev.igb.0.dropped: 0 dev.igb.0.tx_dma_fail: 0 dev.igb.0.rx_overruns: 0 dev.igb.0.watchdog_timeouts: 0 dev.igb.0.device_control: 1488978497 dev.igb.0.rx_control: 67272738 dev.igb.0.interrupt_mask: 4 dev.igb.0.extended_int_mask: 2147483655 dev.igb.0.tx_buf_alloc: 0 dev.igb.0.rx_buf_alloc: 0 dev.igb.0.fc_high_water: 47488 dev.igb.0.fc_low_water: 47472 dev.igb.0.queue0.no_desc_avail: 0 dev.igb.0.queue0.tx_packets: 9 dev.igb.0.queue0.rx_packets: 66 dev.igb.0.queue0.rx_bytes: 5992 dev.igb.0.queue0.lro_queued: 0 dev.igb.0.queue0.lro_flushed: 0 dev.igb.0.queue1.no_desc_avail: 0 dev.igb.0.queue1.tx_packets: 97 dev.igb.0.queue1.rx_packets: 133 dev.igb.0.queue1.rx_bytes: 14907 dev.igb.0.queue1.lro_queued: 0 dev.igb.0.queue1.lro_flushed: 0 dev.igb.0.mac_stats.excess_coll: 0 dev.igb.0.mac_stats.single_coll: 0 dev.igb.0.mac_stats.multiple_coll: 0 dev.igb.0.mac_stats.late_coll: 0 dev.igb.0.mac_stats.collision_count: 0 dev.igb.0.mac_stats.symbol_errors: 0 dev.igb.0.mac_stats.sequence_errors: 0 dev.igb.0.mac_stats.defer_count: 0 dev.igb.0.mac_stats.missed_packets: 0 dev.igb.0.mac_stats.recv_no_buff: 0 dev.igb.0.mac_stats.recv_undersize: 0 dev.igb.0.mac_stats.recv_fragmented: 0 dev.igb.0.mac_stats.recv_oversize: 0 dev.igb.0.mac_stats.recv_jabber: 0 dev.igb.0.mac_stats.recv_errs: 0 dev.igb.0.mac_stats.crc_errs: 0 dev.igb.0.mac_stats.alignment_errs: 0 dev.igb.0.mac_stats.coll_ext_errs: 0 dev.igb.0.mac_stats.xon_recvd: 0 dev.igb.0.mac_stats.xon_txd: 0 dev.igb.0.mac_stats.xoff_recvd: 0 dev.igb.0.mac_stats.xoff_txd: 0 dev.igb.0.mac_stats.total_pkts_recvd: 770 dev.igb.0.mac_stats.good_pkts_recvd: 191 dev.igb.0.mac_stats.bcast_pkts_recvd: 44 dev.igb.0.mac_stats.mcast_pkts_recvd: 19 dev.igb.0.mac_stats.rx_frames_64: 95 dev.igb.0.mac_stats.rx_frames_65_127: 74 dev.igb.0.mac_stats.rx_frames_128_255: 14 dev.igb.0.mac_stats.rx_frames_256_511: 5 dev.igb.0.mac_stats.rx_frames_512_1023: 3 dev.igb.0.mac_stats.rx_frames_1024_1522: 0 dev.igb.0.mac_stats.good_octets_recvd: 21099 dev.igb.0.mac_stats.good_octets_txd: 24521 dev.igb.0.mac_stats.total_pkts_txd: 101 dev.igb.0.mac_stats.good_pkts_txd: 101 dev.igb.0.mac_stats.bcast_pkts_txd: 3 dev.igb.0.mac_stats.mcast_pkts_txd: 0 dev.igb.0.mac_stats.tx_frames_64: 6 dev.igb.0.mac_stats.tx_frames_65_127: 24 dev.igb.0.mac_stats.tx_frames_128_255: 57 dev.igb.0.mac_stats.tx_frames_256_511: 3 dev.igb.0.mac_stats.tx_frames_512_1023: 7 dev.igb.0.mac_stats.tx_frames_1024_1522: 4 dev.igb.0.mac_stats.tso_txd: 4 dev.igb.0.mac_stats.tso_ctx_fail: 0 dev.igb.0.interrupts.asserts: 1653 dev.igb.0.interrupts.rx_pkt_timer: 191 dev.igb.0.interrupts.rx_abs_timer: 0 dev.igb.0.interrupts.tx_pkt_timer: 0 dev.igb.0.interrupts.tx_abs_timer: 191 dev.igb.0.interrupts.tx_queue_empty: 101 dev.igb.0.interrupts.tx_queue_min_thresh: 0 dev.igb.0.interrupts.rx_desc_min_thresh: 0 dev.igb.0.interrupts.rx_overrun: 0 dev.igb.0.host.breaker_tx_pkt: 0 dev.igb.0.host.host_tx_pkt_discard: 0 dev.igb.0.host.rx_pkt: 0 dev.igb.0.host.breaker_rx_pkts: 0 dev.igb.0.host.breaker_rx_pkt_drop: 0 dev.igb.0.host.tx_good_pkt: 0 dev.igb.0.host.breaker_tx_pkt_drop: 0 dev.igb.0.host.rx_good_bytes: 21099 dev.igb.0.host.tx_good_bytes: 24521 dev.igb.0.host.length_errors: 0 dev.igb.0.host.serdes_violation_pkt: 0 dev.igb.0.host.header_redir_missed: 0 signature.asc Description: OpenPGP digital signature
Re: FreeBSD in Google Code-In 2012? You can help too!
On Mon, Oct 22, 2012 at 11:46:21AM -0700, Adrian Chadd wrote: > That wiki site has a distinct lack of help about: > > * what is required from us; > * what the target is (kids, right?) > * some examples of good and bad projects. > > Right now I have absolutely no idea what would constitute a good or > bad coding project. :/ > I updated the Wiki with "Sample ideas" section: http://wiki.freebsd.org/GoogleCodeIn/2012Tasks -- Wojciech A. Koszek wkos...@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problem reading vitals from Gigabyte H77-DH3H
Hello Jeremy, Monday, October 22, 2012, 9:15:29 AM, you wrote: >> Please let me know if this is enough. > I'll repeat what I wrote: > If I could get within the bowels of Gigabyte and actually talk to a > **real engineer** and not tech support, I could find out if their > GA-H77-DS3H motherboard has SMBus tie-ins for their H/W monitoring chip. > If it does, I **absolutely** could add PROPER support for it to > bsdhwmon. Ok, I guess I won't be much of help here. Do you think trying to find developers through linked-in could work? >> As for the picture of the motherboard, this one >> (http://www.nix.ru/autocatalog/motherboards_gigabyte/135869_2245_draft.jpg) >> looks way better than any of my picture. > The H/W monitoring and Super I/O chip on this board is from iTE, but I > cannot read the silkscreening. The chip model matters. It says: IT8892E 1216-FXS ZC0FYB [snip] > Supermicro Technical Support, comparatively, understands the above > question and will give full documentation for each board you ask for. > I've asked them for 10-12 boards "in bulk" once, and they provided all > the documentation for every board. It takes them about 2 weeks to get > it to you -- because they have to get it from an actual engineer. But > getting this from consumer-focused manufacturers (ex. Asus, Gigabyte, > MSI, and even Intel) is difficult. Don't ask me why. Is there somewhere a list of recommended computer components (or companies) that are helpful, so people who are building computers could take that into account? If I had something like that I would use it when building the box, since its function is to run FreeBSD. > bsdhwmon has no support for iTE chips at this time. It only works with > Supermicro motherboards which (so far) have been (mostly) Winbond chips > (now known as Nuvoton). Some Supermicro boards are also very unique > and strange, such as some of their higher-end blade-based boards, where > things are done very uniquely (in some cases, *2* H/W monitoring chips > are used on the same board, with multiple SMBus slave addresses). Any plans to add support in the future? Otherwise I guess I'll have to live with Andriy's solution. While it's not "kosher" at least provides temperature and fan speed (hopefully the values are correct). The primary reason for starting the thread was discovering that values in hw.acpi.thermal are not real. I though all devices were cool until my computer started freezing after 3 weeks of operation. -- Best regards, Derekmailto:tak...@takeda.tk There are two ways to construct a software design. Make it so simple that there are obviously no deficiencies; or make it so complicated that there are no obvious deficiencies. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
