Merge branch 'linus' into x86/timers

TAGS

vmlinux*

!vmlinux.lds.S

!vmlinux.lds.h

System.map

Module.markers

Module.symvers

    runs an instance of gdb against the vmlinux file which contains

    the symbols (not boot image such as bzImage, zImage, uImage...).

    In gdb the developer specifies the connection parameters and

    connects to kgdb.  Depending on which kgdb I/O modules exist in

    the kernel for a given architecture, it may be possible to debug

    the test machine's kernel with the development machine using a

    rs232 or ethernet connection.

    connects to kgdb.  The type of connection a developer makes with

    gdb depends on the availability of kgdb I/O modules compiled as

    builtin's or kernel modules in the test machine's kernel.

    </para>

  </chapter>

  <chapter id="CompilingAKernel">

  </para>

  <para>

  IMPORTANT NOTE: Using this option with kgdb over the console

  (kgdboc) or kgdb over ethernet (kgdboe) is not supported.

  (kgdboc) is not supported.

  </para>

  </sect1>

  </chapter>

    (gdb) target remote /dev/ttyS0

    </programlisting>

    <para>

    Example (kgdb to a terminal server):

    Example (kgdb to a terminal server on tcp port 2012):

    </para>

    <programlisting>

    % gdb ./vmlinux

    (gdb) target remote udp:192.168.2.2:6443

    </programlisting>

    <para>

    Example (kgdb over ethernet):

    </para>

    <programlisting>

    % gdb ./vmlinux

    (gdb) target remote udp:192.168.2.2:6443

    (gdb) target remote 192.168.2.2:2012

    </programlisting>

    <para>

    Once connected, you can debug a kernel the way you would debug an

   2  : search cores in a package.

   3  : search cpus in a node [= system wide on non-NUMA system]

 ( 4  : search nodes in a chunk of node [on NUMA system] )

 ( 5~ : search system wide [on NUMA system])

 ( 5  : search system wide [on NUMA system] )

This file is per-cpuset and affect the sched domain where the cpuset

belongs to.  Therefore if the flag 'sched_load_balance' of a cpuset

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

The libsensors library offers an interface to the raw sensors data

through the sysfs interface. See libsensors documentation and source for

further information. As of writing this document, libsensors

(from lm_sensors 2.8.3) is heavily chip-dependent. Adding or updating

support for any given chip requires modifying the library's code.

This is because libsensors was written for the procfs interface

older kernel modules were using, which wasn't standardized enough.

Recent versions of libsensors (from lm_sensors 2.8.2 and later) have

support for the sysfs interface, though.

The new sysfs interface was designed to be as chip-independent as

possible.

through the sysfs interface. Since lm-sensors 3.0.0, libsensors is

completely chip-independent. It assumes that all the kernel drivers

implement the standard sysfs interface described in this document.

This makes adding or updating support for any given chip very easy, as

libsensors, and applications using it, do not need to be modified.

This is a major improvement compared to lm-sensors 2.

Note that motherboards vary widely in the connections to sensor chips.

There is no standard that ensures, for example, that the second

will have to implement conversion, labeling and hiding of inputs. For

this reason, it is still not recommended to bypass the library.

If you are developing a userspace application please send us feedback on

this standard.

Note that this standard isn't completely established yet, so it is subject

to changes. If you are writing a new hardware monitoring driver those

features can't seem to fit in this interface, please contact us with your

extension proposal. Keep in mind that backward compatibility must be

preserved.

Each chip gets its own directory in the sysfs /sys/devices tree.  To

find all sensor chips, it is easier to follow the device symlinks from

/sys/class/hwmon/hwmon*.

Up to lm-sensors 3.0.0, libsensors looks for hardware monitoring attributes

in the "physical" device directory. Since lm-sensors 3.0.1, attributes found

in the hwmon "class" device directory are also supported. Complex drivers

(e.g. drivers for multifunction chips) may want to use this possibility to

avoid namespace pollution. The only drawback will be that older versions of

libsensors won't support the driver in question.

All sysfs values are fixed point numbers.

There is only one value per file, unlike the older /proc specification.

S:	Maintained

W83791D HARDWARE MONITORING DRIVER

P:	Charles Spirakis

M:	bezaur@gmail.com

P:	Marc Hulsman

M:	m.hulsman@tudelft.nl

L:	lm-sensors@lm-sensors.org

S:	Odd Fixes

S:	Maintained

W83793 HARDWARE MONITORING DRIVER

P:	Rudolf Marek