Re: kgdb ported to devel/gdb

2015-10-02 Thread Andriy Gapon 
On 01/09/2015 00:32, John Baldwin wrote:
> Over the past several months I have ported kgdb to the version of gdb in 
> ports.
> I have a pending patch to the gdb port to add fork following, but once that is
> done (and possibly after updating to 7.10) I will try to add my existing work
> as a KGDB option on the port.  Until such time, you can try the newer kgdb by
> checking out my branch from git.
> 
> Here's my cheat sheet on how to build the newer kgdb.  Note that if you build
> a world with my cross-libkvm patches you should get a kgdb that can debug
> i386 cores on amd64 and vice versa.
> 
> All of the targets that the native devel/gdb support have their backends
> ported (so x86, sparc64, powerpc and powerpc64).  I have not yet ported
> arm or mips since those don't work for userland yet in upstream gdb.  I
> have only compiled non-x86 backends.  Testing of the new kgdb on sparc64
> and powerpc would be appreciated.
> 
> Steps:
> 
> % git clone https://github.com/bsdjhb/gdb.git
> % git checkout freebsd-7.9.1-kgdb
> % fetch http://www.freebsd.org/~jhb/gdb/build
> % pkg install devel/gdb
> 
> # Having gdb installed will mean you get the python bindings in the right
> # place.
> 
> % pkg install gmake
> 
> # I think this is the only build tool you need?
> 
> % ./build
> % cd obj
> 
> # Replace 'obj' with 'obj.' for all but amd64
> 
> % gmake
> 
> # ... wait
> 
> You will now have a binary at 'obj/gdb/kgdb'.  I just run it from my obj
> tree currently when testing.  Once it becomes part of the port it will get
> installed as /usr/local/bin/kgdb791 or some such.

John,

first of all, thank you very much for this!

I followed your instructions substituting freebsd-7.10-kgdb for
freebsd-7.9.1-kgdb branch (devel/gdb is also at version 7.10) and the build
process worked just fine.
However, when I try to use the new kgdb it works, but I get some annoying
diagnostics:

(kgdb) bt
Python Exception  Installation error:
gdb.execute_unwinders function is missing:
Python Exception  No module named gdb.frames:
#0  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:291
#1  0x8063453f in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:359
Python Exception  Installation error:
gdb.execute_unwinders function is missing:
Python Exception  Installation error:
gdb.execute_unwinders function is missing:
#2  0x80634ba4 in vpanic (fmt=, ap=) at
/usr/src/sys/kern/kern_shutdown.c:635
Python Exception  Installation error:
gdb.execute_unwinders function is missing:
#3  0x806348a3 in panic (fmt=) at
/usr/src/sys/kern/kern_shutdown.c:568
Python Exception  Installation error:
gdb.execute_unwinders function is missing:
#4  0x8041bba7 in db_panic (addr=,
have_addr=, count=, modif=) at
/usr/src/sys/ddb/db_command.c:473
Python Exception  Installation error:
gdb.execute_unwinders function is missing:
#5  0x8041b67b in db_command (last_cmdp=, cmd_table=0x0,
dopager=) at /usr/src/sys/ddb/db_command.c:440
#6  0x8041b524 in db_command_loop () at 
/usr/src/sys/ddb/db_command.c:493
Python Exception  Installation error:
gdb.execute_unwinders function is missing:
#7  0x8041de0b in db_trap (type=, code=) at
/usr/src/sys/ddb/db_main.c:251
Python Exception  Installation error:
gdb.execute_unwinders function is missing:
Python Exception  Installation error:
gdb.execute_unwinders function is missing:
#8  0x80669de8 in kdb_trap (type=19, code=0, tf=0x80f976d0
) at /usr/src/sys/kern/subr_kdb.c:653
Python Exception  Installation error:
gdb.execute_unwinders function is missing:
#9  0x80820d26 in trap (frame=0x80f976d0 ) at
/usr/src/sys/amd64/amd64/trap.c:381
#10 0x80809623 in nmi_calltrap () at
/usr/src/sys/amd64/amd64/exception.S:514
Python Exception  Installation error:
gdb.execute_unwinders function is missing:
#11 0x80619e1f in __mtx_assert (c=, what=,
file=, line=) at 
/usr/src/sys/kern/kern_mutex.c:842
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Did I miss something?
Thanks!

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD_HEAD_amd64_gcc4.9 - Build #589 - Fixed

2015-10-02 Thread jenkins-admin 
FreeBSD_HEAD_amd64_gcc4.9 - Build #589 - Fixed:

Build information: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/589/
Full change log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/589/changes
Full build log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/589/console

Change summaries:

288488 by mav:
Document CD block size of 2048.

288487 by ed:
Make truss print CloudABI system call names.

This change adds the bits that are necessary to fetch system call
arguments and return values from trapframes for CloudABI. This allows us
to properly print system calls with the right name. We need to make sure
that we properly convert error numbers when system calls fail.

We still need to improve truss to pretty-print some of the system calls
that have flags.

288486 by mav:
Set default block size for CD to expected 2048 bytes.

288485 by cperciva:
Final step of eliminating the "games" distribution: Merge src/games
(or what's left of it, at least) into src/usr.bin.

This change will not be MFCed.

Discussed at:   EuroBSDCon 2014
Committed from: EuroBSDCon 2015

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: kgdb ported to devel/gdb

2015-10-02 Thread Navdeep Parhar 
On Fri, Oct 02, 2015 at 09:19:13AM +0300, Andriy Gapon wrote:
> On 01/09/2015 00:32, John Baldwin wrote:
> > Over the past several months I have ported kgdb to the version of gdb in 
> > ports.
> > I have a pending patch to the gdb port to add fork following, but once that 
> > is
> > done (and possibly after updating to 7.10) I will try to add my existing 
> > work
> > as a KGDB option on the port.  Until such time, you can try the newer kgdb 
> > by
> > checking out my branch from git.
> > 
> > Here's my cheat sheet on how to build the newer kgdb.  Note that if you 
> > build
> > a world with my cross-libkvm patches you should get a kgdb that can debug
> > i386 cores on amd64 and vice versa.
> > 
> > All of the targets that the native devel/gdb support have their backends
> > ported (so x86, sparc64, powerpc and powerpc64).  I have not yet ported
> > arm or mips since those don't work for userland yet in upstream gdb.  I
> > have only compiled non-x86 backends.  Testing of the new kgdb on sparc64
> > and powerpc would be appreciated.
> > 
> > Steps:
> > 
> > % git clone https://github.com/bsdjhb/gdb.git
> > % git checkout freebsd-7.9.1-kgdb
> > % fetch http://www.freebsd.org/~jhb/gdb/build
> > % pkg install devel/gdb
> > 
> > # Having gdb installed will mean you get the python bindings in the right
> > # place.
> > 
> > % pkg install gmake
> > 
> > # I think this is the only build tool you need?
> > 
> > % ./build
> > % cd obj
> > 
> > # Replace 'obj' with 'obj.' for all but amd64
> > 
> > % gmake
> > 
> > # ... wait
> > 
> > You will now have a binary at 'obj/gdb/kgdb'.  I just run it from my obj
> > tree currently when testing.  Once it becomes part of the port it will get
> > installed as /usr/local/bin/kgdb791 or some such.
> 
> John,
> 
> first of all, thank you very much for this!
> 
> I followed your instructions substituting freebsd-7.10-kgdb for
> freebsd-7.9.1-kgdb branch (devel/gdb is also at version 7.10) and the build
> process worked just fine.
> However, when I try to use the new kgdb it works, but I get some annoying
> diagnostics:
> 
> ...

Andriy,

The patch is also available in D3727.  I downloaded the raw diff from there,
applied it to $PORTS/devel/gdb, and built it as a port (with the KGDB support
option enabled of course).  Everything works.  Can you try that?

https://reviews.freebsd.org/D3727

Regards,
Navdeep
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: getblk: size(131072) > MAXBCACHEBUF(65536)

2015-10-02 Thread Fabian Keil 
Mark Johnston  wrote:

> On Thu, Oct 01, 2015 at 03:23:56PM +0200, Fabian Keil wrote:
> > Shortly after upgrading to a kernel based on r288437 I got the following
> > panic:
> > 
> > Unread portion of the kernel message buffer:
> > [5112] panic: getblk: size(131072) > MAXBCACHEBUF(65536)
> > [...]

> Thanks for the report. This should be fixed as of r288451. (Sorry for
> misspelling your first name in the commit message!)

No problem. Thanks for the quick fix.

Fabian


pgpF8znVSGYfp.pgp
Description: OpenPGP digital signature

FreeBSD_HEAD_amd64_gcc4.9 - Build #588 - Failure

2015-10-02 Thread jenkins-admin 
FreeBSD_HEAD_amd64_gcc4.9 - Build #588 - Failure:

Build information: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/588/
Full change log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/588/changes
Full build log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/588/console

Change summaries:

288484 by phk:
Fail the sbuf if vsnprintf(3) fails.

288482 by araujo:
The rpc.yppasswdd has an option to not allow shell changes (-s), but is
always passed a shell by the remote yppasswd. If an NIS client overrides the
shell provided by the ypserv, then yppasswd (pam_unix, actually, afaict)
will pass this new shell to the yppasswdd. If this shell has been set on the
client to a shell which is invalid on the server, a user will never be able
to change their password on the client.

PR: 67142
Submitted by:   russ...@rucus.ru.ac.za
Approved by:bapt (mentor)
Sponsored by:   EuroBSDCon Sweden.



The end of the build log:

[...truncated 177123 lines...]
 ^
/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include/c++/v1/string:818:1:
 warning: 'static char16_t* 
std::__1::char_traits::assign(std::__1::char_traits::char_type*,
 size_t, std::__1::char_traits::char_type)': visibility attribute 
ignored because it [-Wattributes]
 char_traits::assign(char_type* __s, size_t __n, char_type __a)
 ^
/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include/c++/v1/string:734:29:
 warning: conflicts with previous declaration here [-Wattributes]
 static char_type*   assign(char_type* __s, size_t __n, char_type __a);
 ^
/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include/c++/v1/string:863:1:
 warning: 'static int std::__1::char_traits::compare(const 
char_type*, const char_type*, size_t)': visibility attribute ignored because it 
[-Wattributes]
 char_traits::compare(const char_type* __s1, const char_type* __s2, 
size_t __n)
 ^
/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include/c++/v1/string:842:29:
 warning: conflicts with previous declaration here [-Wattributes]
 static int  compare(const char_type* __s1, const char_type* 
__s2, size_t __n);
 ^
/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include/c++/v1/string:877:1:
 warning: 'static size_t std::__1::char_traits::length(const 
char_type*)': visibility attribute ignored because it [-Wattributes]
 char_traits::length(const char_type* __s)
 ^
/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include/c++/v1/string:843:29:
 warning: conflicts with previous declaration here [-Wattributes]
 static size_t   length(const char_type* __s);
 ^
/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include/c++/v1/string:887:1:
 warning: 'static const char32_t* std::__1::char_traits::find(const 
char_type*, size_t, const char_type&)': visibility attribute ignored because it 
[-Wattributes]
 char_traits::find(const char_type* __s, size_t __n, const char_type& 
__a)
 ^
/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include/c++/v1/string:844:29:
 warning: conflicts with previous declaration here [-Wattributes]
 static const char_type* find(const char_type* __s, size_t __n, const 
char_type& __a);
 ^
/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include/c++/v1/string:900:1:
 warning: 'static char32_t* 
std::__1::char_traits::move(std::__1::char_traits::char_type*,
 const char_type*, size_t)': visibility attribute ignored because it 
[-Wattributes]
 char_traits::move(char_type* __s1, const char_type* __s2, size_t __n)
 ^
/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include/c++/v1/string:845:29:
 warning: conflicts with previous declaration here [-Wattributes]
 static char_type*   move(char_type* __s1, const char_type* __s2, 
size_t __n);
 ^
/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include/c++/v1/string:920:1:
 warning: 'static char32_t* 
std::__1::char_traits::copy(std::__1::char_traits::char_type*,
 const char_type*, size_t)': visibility attribute ignored because it 
[-Wattributes]
 char_traits::copy(char_type* __s1, const char_type* __s2, size_t __n)
 ^
/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include/c++/v1/string:846:29:
 warning: conflicts with previous declaration here [-Wattributes]
 static char_type*   copy(char_type* __s1, const char_type* __s2, 
size_t __n);
 ^
/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include/c++/v1/string:931:1:
 warning: 'static char32_t*

Re: kgdb ported to devel/gdb

2015-10-02 Thread John Baldwin 
On Friday, October 02, 2015 09:19:13 AM Andriy Gapon wrote:
> On 01/09/2015 00:32, John Baldwin wrote:
> > Over the past several months I have ported kgdb to the version of gdb in 
> > ports.
> > I have a pending patch to the gdb port to add fork following, but once that 
> > is
> > done (and possibly after updating to 7.10) I will try to add my existing 
> > work
> > as a KGDB option on the port.  Until such time, you can try the newer kgdb 
> > by
> > checking out my branch from git.
> > 
> > Here's my cheat sheet on how to build the newer kgdb.  Note that if you 
> > build
> > a world with my cross-libkvm patches you should get a kgdb that can debug
> > i386 cores on amd64 and vice versa.
> > 
> > All of the targets that the native devel/gdb support have their backends
> > ported (so x86, sparc64, powerpc and powerpc64).  I have not yet ported
> > arm or mips since those don't work for userland yet in upstream gdb.  I
> > have only compiled non-x86 backends.  Testing of the new kgdb on sparc64
> > and powerpc would be appreciated.
> > 
> > Steps:
> > 
> > % git clone https://github.com/bsdjhb/gdb.git
> > % git checkout freebsd-7.9.1-kgdb
> > % fetch http://www.freebsd.org/~jhb/gdb/build
> > % pkg install devel/gdb
> > 
> > # Having gdb installed will mean you get the python bindings in the right
> > # place.
> > 
> > % pkg install gmake
> > 
> > # I think this is the only build tool you need?
> > 
> > % ./build
> > % cd obj
> > 
> > # Replace 'obj' with 'obj.' for all but amd64
> > 
> > % gmake
> > 
> > # ... wait
> > 
> > You will now have a binary at 'obj/gdb/kgdb'.  I just run it from my obj
> > tree currently when testing.  Once it becomes part of the port it will get
> > installed as /usr/local/bin/kgdb791 or some such.
> 
> John,
> 
> first of all, thank you very much for this!
> 
> I followed your instructions substituting freebsd-7.10-kgdb for
> freebsd-7.9.1-kgdb branch (devel/gdb is also at version 7.10) and the build
> process worked just fine.
> However, when I try to use the new kgdb it works, but I get some annoying
> diagnostics:
> 
> (kgdb) bt
> Python Exception  Installation error:
> gdb.execute_unwinders function is missing:
> Python Exception  No module named gdb.frames:
> #0  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:291
> #1  0x8063453f in kern_reboot (howto=260) at
> /usr/src/sys/kern/kern_shutdown.c:359
> Python Exception  Installation error:
> gdb.execute_unwinders function is missing:
> Python Exception  Installation error:
> gdb.execute_unwinders function is missing:
> #2  0x80634ba4 in vpanic (fmt=, ap=) at
> /usr/src/sys/kern/kern_shutdown.c:635
> Python Exception  Installation error:
> gdb.execute_unwinders function is missing:
> #3  0x806348a3 in panic (fmt=) at
> /usr/src/sys/kern/kern_shutdown.c:568
> Python Exception  Installation error:
> gdb.execute_unwinders function is missing:
> #4  0x8041bba7 in db_panic (addr=,
> have_addr=, count=, modif=) at
> /usr/src/sys/ddb/db_command.c:473
> Python Exception  Installation error:
> gdb.execute_unwinders function is missing:
> #5  0x8041b67b in db_command (last_cmdp=, 
> cmd_table=0x0,
> dopager=) at /usr/src/sys/ddb/db_command.c:440
> #6  0x8041b524 in db_command_loop () at 
> /usr/src/sys/ddb/db_command.c:493
> Python Exception  Installation error:
> gdb.execute_unwinders function is missing:
> #7  0x8041de0b in db_trap (type=, code=) 
> at
> /usr/src/sys/ddb/db_main.c:251
> Python Exception  Installation error:
> gdb.execute_unwinders function is missing:
> Python Exception  Installation error:
> gdb.execute_unwinders function is missing:
> #8  0x80669de8 in kdb_trap (type=19, code=0, tf=0x80f976d0
> ) at /usr/src/sys/kern/subr_kdb.c:653
> Python Exception  Installation error:
> gdb.execute_unwinders function is missing:
> #9  0x80820d26 in trap (frame=0x80f976d0 ) at
> /usr/src/sys/amd64/amd64/trap.c:381
> #10 0x80809623 in nmi_calltrap () at
> /usr/src/sys/amd64/amd64/exception.S:514
> Python Exception  Installation error:
> gdb.execute_unwinders function is missing:
> #11 0x80619e1f in __mtx_assert (c=, what= out>,
> file=, line=) at 
> /usr/src/sys/kern/kern_mutex.c:842
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> 
> Did I miss something?
> Thanks!

I've noticed this as well.  I've taken to building gdb without python support
for my testing when building out of git for now.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT: net/igb broken

2015-10-02 Thread Sean Bruno 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 10/02/15 00:47, O. Hartmann wrote:
> On Thu, 01 Oct 2015 15:39:11 + Eric Joyner 
> wrote:
> 
>> Oliver,
>> 
>> did you try Sean's suggestion?
>> 
>> - Eric
>> 
>> On Tue, Sep 22, 2015 at 1:10 PM Sean Bruno 
>> wrote:
>> 
> 
> 
> On 09/21/15 23:23, O. Hartmann wrote:
> On Mon, 21 Sep 2015 21:13:18 + Eric Joyner
>  wrote:
> 
>> If you do a diff between r288057 and r287761, there are
>> no differences between the sys/dev/e1000, sys/modules/em,
>> and sys/modules/igb directories. Are you sure r287761
>> actually works?
> 
> I'm quite sure r287761 works (and r287762 doesn't), double
> checked this this morning again. I also checked r288093 and
> it is still not working.
> 
> The ensure that I'm not the culprit and stupid here:
> 
> I use a NanoBSD environment and the only thing that gets
> exchanged, is the underlying OS/OS revision. The
> configuration always stays the same. The base system for
> all of my tests is built from a clean source - (deleted
> obj/ dir, clean, fresh build into obj/ for every test I
> ran).
> 
> I realised a funny thing. Playing around with
> enabling/disabling TSO (I have been told that could be the
> culprit in an earlier Email from this list) with the
> commend sequence:
> 
> ifconfig igb1 down ifconfig igb1 -tso ifconfig igb1 up
> ifconfig igb1 down ifconfig igb1 tso ifconfig igb1 up . .
> .
> 
> while a ping is pinging in the background a remote host
> connected to that specific interface, the ping does work
> for a while and dies then after a round trip of roughly 10
> - 20. I can reproduce this.
> 
> is that observation of any help?
> 
> Regards,
> 
> oh
> 
>> 
>> On Mon, Sep 21, 2015 at 1:58 AM O. Hartmann 
>>  wrote:
>> 
>>> On Sat, 19 Sep 2015 11:23:44 -0700 Sean Bruno 
>>>  wrote:
>>> 
> 
> 
> On 09/18/15 10:20, Eric Joyner wrote:
>> He has an i210 -- he would want to revert 
>> e1000_i210.[ch], too.
>> 
>> Sorry for the thrash Sean -- it sounds like it
>> would be a good idea for you should revert this
>> patch, and Jeff and I can go look at trying these
>> shared code updates and igb changes internally
>> again. We at Intel really could've done a better
>> job of making sure these changes worked across a
>> wider variety of devices.
>> 
>> - Eric
> 
> I've reverted the changes to head.  I'll reopen the reviews
> and we can proceed from there.
> 
> sean
> 
> 
>> 
>> On Fri, Sep 18, 2015 at 9:50 AM Sean Bruno 
>> >
>> wrote:
>> 
>> 
>>> 
>>> r287762 broke the system
>> 
>> 
>> Before I revert this changeset *again* can you
>> test revert r287762 from if_igb.c, e1000_82575.c
>> and e1000_82575.h *only*
>> 
>> That narrows down the change quite a bit.
>> 
>> sean
>> ___ 
>> freebsd-current@freebsd.org 
>>  mailing
>> list 
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>
>> 
To unsubscribe, send any mail to
>> "freebsd-current-unsubscr...@freebsd.org 
>> "
>>
>>>
>>>
>> 
I'm now on r288057 on that specific machine, supposedly
>>> reverted changes that seemingly has been identified as
>>> the culprit. Still NO change in behaviour!
>>> 
>>> r287761 works with the same configuration on igb
>>> (i210), any further does not. Not ping/connect from the
>>> outside, no ping/connect from the inside. Tried
>>> different protocols (SAMBA, ssh, LDAP, DNS). Affected
>>> is/are only boxes with the igb driver and i210 chipset
>>> (we do not have other chips covered by igb).
>>> 
>>> Regards, Oliver
>>> 
>> ___ 
>> freebsd-current@freebsd.org mailing list 
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to 
>> "freebsd-current-unsubscr...@freebsd.org"
> 
> 
> 
> 
> For my entertainment (and HPS's), can you run HEAD and revert
> r287775?
> 
> sean
>>> ___ 
>>> freebsd-current@freebsd.org mailing list 
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current To
>>> unsubscribe, send any mail to
>>> "freebsd-current-unsubscr...@freebsd.org"
>>> 
>>

Re: Wrong temperature with AMD and amdtemp.ko

2015-10-02 Thread Jung-uk Kim 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/02/2015 16:49, Willem Jan Withagen wrote:
> 
> Hi
> 
> 10.2-STABLE FreeBSD 10.2-STABLE #0 r287102: Mon Aug 24
> 
> Processor: Opteron 6812, in Supermicro H8SGL
> 
> dev.cpu.7.temperature: 11.1C dev.cpu.6.temperature: 11.1C 
> dev.cpu.5.temperature: 11.1C dev.cpu.4.temperature: 11.1C 
> dev.cpu.3.temperature: 11.1C dev.cpu.2.temperature: 11.1C 
> dev.cpu.1.temperature: 11.1C dev.cpu.0.temperature: 11.1C
> 
> But I'm pretty sure it is not 11.1C in the datacenter
> 
> Or should I not use amdtemp.ko for this?

amdtemp(4):

For Family 10h and later processors, “(the reported temperature) is a
non-physical temperature measured on an arbitrary scale and it does not
represent an actual physical temperature like die or case temperature.
Instead, it specifies the processor temperature relative to the point at
which the system must supply the maximum cooling for the processor's
specified maximum case temperature and maximum thermal power dissipation”
according to BIOS and Kernel Developer's Guide (BKDG) for AMD Processors,
http://developer.amd.com/documentation/guides/Pages/default.aspx.

Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWDvHaAAoJEHyflib82/FGrvwIAIHhM5bDxODIycXkuqoNWutC
MUO7KsFcQuU+pGpV+Ip70ZehRbbdjbo/3sD4oqispWKwKuUgihPBiRn7v/Ad2fxN
crvZ4MJXalQmr7+ipELWVtD8/TkzIX6npLMvjRr/adnkzDleGuEErG45z77w/6uj
SdJVkvAp15Ji1qu2UWXCipg8mWpPvZjgNwDeeK3ryo5ZsE9YaeWOKJG9eP9sjTcx
zoYC7LR/aVFFDZTlx6EY6SLHTZNs/jBsFkr6iF6xeIa9dsnwrI7ebNat8ApGQTX2
sydzIECiElqKiYNwk9XEn+e3aNgryoBhGx2Ax+fWxHHBB+kojhnFBHVQ1Qg2WaE=
=ixlS
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Wrong temperature with AMD and amdtemp.ko

2015-10-02 Thread Don Lewis 
On  2 Oct, Willem Jan Withagen wrote:
> 
> Hi
> 
> 10.2-STABLE FreeBSD 10.2-STABLE #0 r287102: Mon Aug 24
> 
> Processor: Opteron 6812, in Supermicro H8SGL
> 
> dev.cpu.7.temperature: 11.1C
> dev.cpu.6.temperature: 11.1C
> dev.cpu.5.temperature: 11.1C
> dev.cpu.4.temperature: 11.1C
> dev.cpu.3.temperature: 11.1C
> dev.cpu.2.temperature: 11.1C
> dev.cpu.1.temperature: 11.1C
> dev.cpu.0.temperature: 11.1C
> 
> But I'm pretty sure it is not 11.1C in the datacenter
> 
> Or should I not use amdtemp.ko for this?

The definition of the value that can be read from the temperature
register is pretty strange.  For AMD Family 15h processors, the BIOS and
Kernel Developer's Guide (BKDG) says this:

  Tctl is a processor temperature control value used for processor
  thermal management. Tctl is accessible through D18F3xA4[CurTmp].
  Tctl is a temperature on its own scale aligned to the processors
  cooling requirements. Therefore Tctl does not represent a temperature
  which could be measured on the die or the case of the processor.
  Instead, it specifies the processor temperature relative to the
  maximum operating temperature, Tctl,max. Tctl,max is specified in the
  power and thermal data sheet. Tctl is defined as follows for all
  parts:

  A: For Tctl = Tctl_max to 255.875: the temperature of the part is
  [Tctl - Tctl_max] over the maximum operat- ing temperature.  The
  processor may take corrective actions that affects performance, such
  as HTC, to support the return to Tctl range A.

  B: For Tctl = 0 to Tctl_max - 0.125: the temperature of the part is
  [Tctl_max - Tctl] under the maximum operating temperature.

It would be nice to report Tctl_max so that we could at least know how
far the temperature is from the limit, but I don't know if that is
available.  It might be the value in the HtcTmpLmt register, but the
BKDG is unclear about that.  If not, we would have to build a table of
values from the datasheet.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Wrong temperature with AMD and amdtemp.ko

2015-10-02 Thread Willem Jan Withagen 

Hi

10.2-STABLE FreeBSD 10.2-STABLE #0 r287102: Mon Aug 24

Processor: Opteron 6812, in Supermicro H8SGL

dev.cpu.7.temperature: 11.1C
dev.cpu.6.temperature: 11.1C
dev.cpu.5.temperature: 11.1C
dev.cpu.4.temperature: 11.1C
dev.cpu.3.temperature: 11.1C
dev.cpu.2.temperature: 11.1C
dev.cpu.1.temperature: 11.1C
dev.cpu.0.temperature: 11.1C

But I'm pretty sure it is not 11.1C in the datacenter

Or should I not use amdtemp.ko for this?

--WjW


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT: net/igb broken

2015-10-02 Thread O. Hartmann 
On Thu, 01 Oct 2015 15:39:11 +
Eric Joyner  wrote:

> Oliver,
> 
> did you try Sean's suggestion?
> 
> - Eric
> 
> On Tue, Sep 22, 2015 at 1:10 PM Sean Bruno  wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> >
> >
> > On 09/21/15 23:23, O. Hartmann wrote:
> > > On Mon, 21 Sep 2015 21:13:18 + Eric Joyner 
> > > wrote:
> > >
> > >> If you do a diff between r288057 and r287761, there are no
> > >> differences between the sys/dev/e1000, sys/modules/em, and
> > >> sys/modules/igb directories. Are you sure r287761 actually
> > >> works?
> > >
> > > I'm quite sure r287761 works (and r287762 doesn't), double checked
> > > this this morning again. I also checked r288093 and it is still not
> > > working.
> > >
> > > The ensure that I'm not the culprit and stupid here:
> > >
> > > I use a NanoBSD environment and the only thing that gets exchanged,
> > > is the underlying OS/OS revision. The configuration always stays
> > > the same. The base system for all of my tests is built from a clean
> > > source - (deleted obj/ dir, clean, fresh build into obj/ for every
> > > test I ran).
> > >
> > > I realised a funny thing. Playing around with enabling/disabling
> > > TSO (I have been told that could be the culprit in an earlier Email
> > > from this list) with the commend sequence:
> > >
> > > ifconfig igb1 down ifconfig igb1 -tso ifconfig igb1 up ifconfig
> > > igb1 down ifconfig igb1 tso ifconfig igb1 up . . .
> > >
> > > while a ping is pinging in the background a remote host connected
> > > to that specific interface, the ping does work for a while and dies
> > > then after a round trip of roughly 10 - 20. I can reproduce this.
> > >
> > > is that observation of any help?
> > >
> > > Regards,
> > >
> > > oh
> > >
> > >>
> > >> On Mon, Sep 21, 2015 at 1:58 AM O. Hartmann
> > >>  wrote:
> > >>
> > >>> On Sat, 19 Sep 2015 11:23:44 -0700 Sean Bruno
> > >>>  wrote:
> > >>>
> > >
> > >
> > > On 09/18/15 10:20, Eric Joyner wrote:
> > >> He has an i210 -- he would want to revert
> > >> e1000_i210.[ch], too.
> > >>
> > >> Sorry for the thrash Sean -- it sounds like it would be a
> > >> good idea for you should revert this patch, and Jeff and
> > >> I can go look at trying these shared code updates and igb
> > >> changes internally again. We at Intel really could've
> > >> done a better job of making sure these changes worked
> > >> across a wider variety of devices.
> > >>
> > >> - Eric
> > >
> > > I've reverted the changes to head.  I'll reopen the reviews and we
> > > can proceed from there.
> > >
> > > sean
> > >
> > >
> > >>
> > >> On Fri, Sep 18, 2015 at 9:50 AM Sean Bruno
> > >> > wrote:
> > >>
> > >>
> > >>>
> > >>> r287762 broke the system
> > >>
> > >>
> > >> Before I revert this changeset *again* can you test
> > >> revert r287762 from if_igb.c, e1000_82575.c and
> > >> e1000_82575.h *only*
> > >>
> > >> That narrows down the change quite a bit.
> > >>
> > >> sean ___
> > >> freebsd-current@freebsd.org
> > >>  mailing list
> > >> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > >> To unsubscribe, send any mail to
> > >> "freebsd-current-unsubscr...@freebsd.org
> > >> "
> > >>
> > >>>
> > >>> I'm now on r288057 on that specific machine, supposedly
> > >>> reverted changes that seemingly has been identified as the
> > >>> culprit. Still NO change in behaviour!
> > >>>
> > >>> r287761 works with the same configuration on igb (i210), any
> > >>> further does not. Not ping/connect from the outside, no
> > >>> ping/connect from the inside. Tried different protocols (SAMBA,
> > >>> ssh, LDAP, DNS). Affected is/are only boxes with the igb driver
> > >>> and i210 chipset (we do not have other chips covered by igb).
> > >>>
> > >>> Regards, Oliver
> > >>>
> > >> ___
> > >> freebsd-current@freebsd.org mailing list
> > >> https://lists.freebsd.org/mailman/listinfo/freebsd-current To
> > >> unsubscribe, send any mail to
> > >> "freebsd-current-unsubscr...@freebsd.org"
> > >
> > >
> >
> >
> > For my entertainment (and HPS's), can you run HEAD and revert r287775?
> >
> > sean
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v2
> >
> > iQF8BAEBCgBmBQJWAbWOXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx
> > MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kPTAH/jmm1tudLRYVtC+xb9NXHQgr
> > dl8/fZC8/xL3m0EVM8pWdKlRbF1tHUDSB/2ftYUBEe6SIkab2IZx2Z/0VgdflrbB
> > 05HQUuq1yM3dYBiEAjyM0oK6lfeWu2Jg8nOaA5YWi1GO2OfkuDfXRUkK3sm7xa0C
> >