Merge branch 'next/isa' into topic/misc
This commit is contained in:
Takashi Iwai
commit
b89371621e
|
|
@ -25,6 +25,7 @@
|
|||
*.elf
|
||||
*.bin
|
||||
*.gz
|
||||
*.bz2
|
||||
*.lzma
|
||||
*.patch
|
||||
*.gcno
|
||||
|
|
|
|||
|
|
@ -0,0 +1,8 @@
|
|||
What: /sys/bus/pci/drivers/qla2xxx/.../devices/*
|
||||
Date: September 2009
|
||||
Contact: QLogic Linux Driver <linux-driver@qlogic.com>
|
||||
Description: qla2xxx-udev.sh currently looks for uevent CHANGE events to
|
||||
signal a firmware-dump has been generated by the driver and is
|
||||
ready for retrieval.
|
||||
Users: qla2xxx-udev.sh. Proposed changes should be mailed to
|
||||
linux-driver@qlogic.com
|
||||
|
|
@ -8,7 +8,7 @@ Description:
|
|||
1 - major number
|
||||
2 - minor mumber
|
||||
3 - device name
|
||||
4 - reads completed succesfully
|
||||
4 - reads completed successfully
|
||||
5 - reads merged
|
||||
6 - sectors read
|
||||
7 - time spent reading (ms)
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Contact: Jerome Marchand <jmarchan@redhat.com>
|
|||
Description:
|
||||
The /sys/block/<disk>/stat files displays the I/O
|
||||
statistics of disk <disk>. They contain 11 fields:
|
||||
1 - reads completed succesfully
|
||||
1 - reads completed successfully
|
||||
2 - reads merged
|
||||
3 - sectors read
|
||||
4 - time spent reading (ms)
|
||||
|
|
|
|||
|
|
@ -214,7 +214,7 @@ most specific mask.
|
|||
Here is pseudo-code showing how this might be done:
|
||||
|
||||
#define PLAYBACK_ADDRESS_BITS DMA_BIT_MASK(32)
|
||||
#define RECORD_ADDRESS_BITS 0x00ffffff
|
||||
#define RECORD_ADDRESS_BITS DMA_BIT_MASK(24)
|
||||
|
||||
struct my_sound_card *card;
|
||||
struct pci_dev *pdev;
|
||||
|
|
@ -224,14 +224,14 @@ Here is pseudo-code showing how this might be done:
|
|||
card->playback_enabled = 1;
|
||||
} else {
|
||||
card->playback_enabled = 0;
|
||||
printk(KERN_WARN "%s: Playback disabled due to DMA limitations.\n",
|
||||
printk(KERN_WARNING "%s: Playback disabled due to DMA limitations.\n",
|
||||
card->name);
|
||||
}
|
||||
if (!pci_set_dma_mask(pdev, RECORD_ADDRESS_BITS)) {
|
||||
card->record_enabled = 1;
|
||||
} else {
|
||||
card->record_enabled = 0;
|
||||
printk(KERN_WARN "%s: Record disabled due to DMA limitations.\n",
|
||||
printk(KERN_WARNING "%s: Record disabled due to DMA limitations.\n",
|
||||
card->name);
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -293,10 +293,23 @@ X!Idrivers/video/console/fonts.c
|
|||
|
||||
<chapter id="input_subsystem">
|
||||
<title>Input Subsystem</title>
|
||||
<sect1><title>Input core</title>
|
||||
!Iinclude/linux/input.h
|
||||
!Edrivers/input/input.c
|
||||
!Edrivers/input/ff-core.c
|
||||
!Edrivers/input/ff-memless.c
|
||||
</sect1>
|
||||
<sect1><title>Polled input devices</title>
|
||||
!Iinclude/linux/input-polldev.h
|
||||
!Edrivers/input/input-polldev.c
|
||||
</sect1>
|
||||
<sect1><title>Matrix keyboars/keypads</title>
|
||||
!Iinclude/linux/input/matrix_keypad.h
|
||||
</sect1>
|
||||
<sect1><title>Sparse keymap support</title>
|
||||
!Iinclude/linux/input/sparse-keymap.h
|
||||
!Edrivers/input/sparse-keymap.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="spi">
|
||||
|
|
|
|||
|
|
@ -29,6 +29,14 @@
|
|||
|
||||
<revhistory>
|
||||
<!-- Put document revisions here, newest first. -->
|
||||
<revision>
|
||||
<revnumber>2.0.2</revnumber>
|
||||
<date>2009-10-25</date>
|
||||
<authorinitials>mcc</authorinitials>
|
||||
<revremark>
|
||||
documents FE_SET_FRONTEND_TUNE_MODE and FE_DISHETWORK_SEND_LEGACY_CMD ioctls.
|
||||
</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>2.0.1</revnumber>
|
||||
<date>2009-09-16</date>
|
||||
|
|
@ -85,3 +93,8 @@ Added ISDB-T test originally written by Patrick Boettcher
|
|||
&sub-examples;
|
||||
</chapter>
|
||||
<!-- END OF CHAPTERS -->
|
||||
<appendix id="frontend_h">
|
||||
<title>DVB Frontend Header File</title>
|
||||
&sub-frontend-h;
|
||||
</appendix>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,6 @@
|
|||
<section id="FE_GET_PROPERTY">
|
||||
<title>FE_GET_PROPERTY/FE_SET_PROPERTY</title>
|
||||
|
||||
<section id="isdbt">
|
||||
<title>ISDB-T frontend</title>
|
||||
<para>This section describes shortly what are the possible parameters in the Linux
|
||||
|
|
@ -312,3 +315,4 @@
|
|||
</section>
|
||||
</section>
|
||||
</section>
|
||||
</section>
|
||||
|
|
@ -0,0 +1,415 @@
|
|||
<programlisting>
|
||||
/*
|
||||
* frontend.h
|
||||
*
|
||||
* Copyright (C) 2000 Marcus Metzler <marcus@convergence.de>
|
||||
* Ralph Metzler <ralph@convergence.de>
|
||||
* Holger Waechtler <holger@convergence.de>
|
||||
* Andre Draszik <ad@convergence.de>
|
||||
* for convergence integrated media GmbH
|
||||
*
|
||||
* This program is free software; you can redistribute it and/or
|
||||
* modify it under the terms of the GNU Lesser General Public License
|
||||
* as published by the Free Software Foundation; either version 2.1
|
||||
* of the License, or (at your option) any later version.
|
||||
*
|
||||
* This program is distributed in the hope that it will be useful,
|
||||
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
* GNU General Public License for more details.
|
||||
*
|
||||
* You should have received a copy of the GNU Lesser General Public License
|
||||
* along with this program; if not, write to the Free Software
|
||||
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
||||
*
|
||||
*/
|
||||
|
||||
#ifndef _DVBFRONTEND_H_
|
||||
#define _DVBFRONTEND_H_
|
||||
|
||||
#include <linux/types.h>
|
||||
|
||||
typedef enum fe_type {
|
||||
FE_QPSK,
|
||||
FE_QAM,
|
||||
FE_OFDM,
|
||||
FE_ATSC
|
||||
} fe_type_t;
|
||||
|
||||
|
||||
typedef enum fe_caps {
|
||||
FE_IS_STUPID = 0,
|
||||
FE_CAN_INVERSION_AUTO = 0x1,
|
||||
FE_CAN_FEC_1_2 = 0x2,
|
||||
FE_CAN_FEC_2_3 = 0x4,
|
||||
FE_CAN_FEC_3_4 = 0x8,
|
||||
FE_CAN_FEC_4_5 = 0x10,
|
||||
FE_CAN_FEC_5_6 = 0x20,
|
||||
FE_CAN_FEC_6_7 = 0x40,
|
||||
FE_CAN_FEC_7_8 = 0x80,
|
||||
FE_CAN_FEC_8_9 = 0x100,
|
||||
FE_CAN_FEC_AUTO = 0x200,
|
||||
FE_CAN_QPSK = 0x400,
|
||||
FE_CAN_QAM_16 = 0x800,
|
||||
FE_CAN_QAM_32 = 0x1000,
|
||||
FE_CAN_QAM_64 = 0x2000,
|
||||
FE_CAN_QAM_128 = 0x4000,
|
||||
FE_CAN_QAM_256 = 0x8000,
|
||||
FE_CAN_QAM_AUTO = 0x10000,
|
||||
FE_CAN_TRANSMISSION_MODE_AUTO = 0x20000,
|
||||
FE_CAN_BANDWIDTH_AUTO = 0x40000,
|
||||
FE_CAN_GUARD_INTERVAL_AUTO = 0x80000,
|
||||
FE_CAN_HIERARCHY_AUTO = 0x100000,
|
||||
FE_CAN_8VSB = 0x200000,
|
||||
FE_CAN_16VSB = 0x400000,
|
||||
FE_HAS_EXTENDED_CAPS = 0x800000, /* We need more bitspace for newer APIs, indicate this. */
|
||||
FE_CAN_2G_MODULATION = 0x10000000, /* frontend supports "2nd generation modulation" (DVB-S2) */
|
||||
FE_NEEDS_BENDING = 0x20000000, /* not supported anymore, don't use (frontend requires frequency bending) */
|
||||
FE_CAN_RECOVER = 0x40000000, /* frontend can recover from a cable unplug automatically */
|
||||
FE_CAN_MUTE_TS = 0x80000000 /* frontend can stop spurious TS data output */
|
||||
} fe_caps_t;
|
||||
|
||||
|
||||
struct dvb_frontend_info {
|
||||
char name[128];
|
||||
fe_type_t type;
|
||||
__u32 frequency_min;
|
||||
__u32 frequency_max;
|
||||
__u32 frequency_stepsize;
|
||||
__u32 frequency_tolerance;
|
||||
__u32 symbol_rate_min;
|
||||
__u32 symbol_rate_max;
|
||||
__u32 symbol_rate_tolerance; /* ppm */
|
||||
__u32 notifier_delay; /* DEPRECATED */
|
||||
fe_caps_t caps;
|
||||
};
|
||||
|
||||
|
||||
/**
|
||||
* Check out the DiSEqC bus spec available on http://www.eutelsat.org/ for
|
||||
* the meaning of this struct...
|
||||
*/
|
||||
struct dvb_diseqc_master_cmd {
|
||||
__u8 msg [6]; /* { framing, address, command, data [3] } */
|
||||
__u8 msg_len; /* valid values are 3...6 */
|
||||
};
|
||||
|
||||
|
||||
struct dvb_diseqc_slave_reply {
|
||||
__u8 msg [4]; /* { framing, data [3] } */
|
||||
__u8 msg_len; /* valid values are 0...4, 0 means no msg */
|
||||
int timeout; /* return from ioctl after timeout ms with */
|
||||
}; /* errorcode when no message was received */
|
||||
|
||||
|
||||
typedef enum fe_sec_voltage {
|
||||
SEC_VOLTAGE_13,
|
||||
SEC_VOLTAGE_18,
|
||||
SEC_VOLTAGE_OFF
|
||||
} fe_sec_voltage_t;
|
||||
|
||||
|
||||
typedef enum fe_sec_tone_mode {
|
||||
SEC_TONE_ON,
|
||||
SEC_TONE_OFF
|
||||
} fe_sec_tone_mode_t;
|
||||
|
||||
|
||||
typedef enum fe_sec_mini_cmd {
|
||||
SEC_MINI_A,
|
||||
SEC_MINI_B
|
||||
} fe_sec_mini_cmd_t;
|
||||
|
||||
|
||||
typedef enum fe_status {
|
||||
FE_HAS_SIGNAL = 0x01, /* found something above the noise level */
|
||||
FE_HAS_CARRIER = 0x02, /* found a DVB signal */
|
||||
FE_HAS_VITERBI = 0x04, /* FEC is stable */
|
||||
FE_HAS_SYNC = 0x08, /* found sync bytes */
|
||||
FE_HAS_LOCK = 0x10, /* everything's working... */
|
||||
FE_TIMEDOUT = 0x20, /* no lock within the last ~2 seconds */
|
||||
FE_REINIT = 0x40 /* frontend was reinitialized, */
|
||||
} fe_status_t; /* application is recommended to reset */
|
||||
/* DiSEqC, tone and parameters */
|
||||
|
||||
typedef enum fe_spectral_inversion {
|
||||
INVERSION_OFF,
|
||||
INVERSION_ON,
|
||||
INVERSION_AUTO
|
||||
} fe_spectral_inversion_t;
|
||||
|
||||
|
||||
typedef enum fe_code_rate {
|
||||
FEC_NONE = 0,
|
||||
FEC_1_2,
|
||||
FEC_2_3,
|
||||
FEC_3_4,
|
||||
FEC_4_5,
|
||||
FEC_5_6,
|
||||
FEC_6_7,
|
||||
FEC_7_8,
|
||||
FEC_8_9,
|
||||
FEC_AUTO,
|
||||
FEC_3_5,
|
||||
FEC_9_10,
|
||||
} fe_code_rate_t;
|
||||
|
||||
|
||||
typedef enum fe_modulation {
|
||||
QPSK,
|
||||
QAM_16,
|
||||
QAM_32,
|
||||
QAM_64,
|
||||
QAM_128,
|
||||
QAM_256,
|
||||
QAM_AUTO,
|
||||
VSB_8,
|
||||
VSB_16,
|
||||
PSK_8,
|
||||
APSK_16,
|
||||
APSK_32,
|
||||
DQPSK,
|
||||
} fe_modulation_t;
|
||||
|
||||
typedef enum fe_transmit_mode {
|
||||
TRANSMISSION_MODE_2K,
|
||||
TRANSMISSION_MODE_8K,
|
||||
TRANSMISSION_MODE_AUTO,
|
||||
TRANSMISSION_MODE_4K
|
||||
} fe_transmit_mode_t;
|
||||
|
||||
typedef enum fe_bandwidth {
|
||||
BANDWIDTH_8_MHZ,
|
||||
BANDWIDTH_7_MHZ,
|
||||
BANDWIDTH_6_MHZ,
|
||||
BANDWIDTH_AUTO
|
||||
} fe_bandwidth_t;
|
||||
|
||||
|
||||
typedef enum fe_guard_interval {
|
||||
GUARD_INTERVAL_1_32,
|
||||
GUARD_INTERVAL_1_16,
|
||||
GUARD_INTERVAL_1_8,
|
||||
GUARD_INTERVAL_1_4,
|
||||
GUARD_INTERVAL_AUTO
|
||||
} fe_guard_interval_t;
|
||||
|
||||
|
||||
typedef enum fe_hierarchy {
|
||||
HIERARCHY_NONE,
|
||||
HIERARCHY_1,
|
||||
HIERARCHY_2,
|
||||
HIERARCHY_4,
|
||||
HIERARCHY_AUTO
|
||||
} fe_hierarchy_t;
|
||||
|
||||
|
||||
struct dvb_qpsk_parameters {
|
||||
__u32 symbol_rate; /* symbol rate in Symbols per second */
|
||||
fe_code_rate_t fec_inner; /* forward error correction (see above) */
|
||||
};
|
||||
|
||||
struct dvb_qam_parameters {
|
||||
__u32 symbol_rate; /* symbol rate in Symbols per second */
|
||||
fe_code_rate_t fec_inner; /* forward error correction (see above) */
|
||||
fe_modulation_t modulation; /* modulation type (see above) */
|
||||
};
|
||||
|
||||
struct dvb_vsb_parameters {
|
||||
fe_modulation_t modulation; /* modulation type (see above) */
|
||||
};
|
||||
|
||||
struct dvb_ofdm_parameters {
|
||||
fe_bandwidth_t bandwidth;
|
||||
fe_code_rate_t code_rate_HP; /* high priority stream code rate */
|
||||
fe_code_rate_t code_rate_LP; /* low priority stream code rate */
|
||||
fe_modulation_t constellation; /* modulation type (see above) */
|
||||
fe_transmit_mode_t transmission_mode;
|
||||
fe_guard_interval_t guard_interval;
|
||||
fe_hierarchy_t hierarchy_information;
|
||||
};
|
||||
|
||||
|
||||
struct dvb_frontend_parameters {
|
||||
__u32 frequency; /* (absolute) frequency in Hz for QAM/OFDM/ATSC */
|
||||
/* intermediate frequency in kHz for QPSK */
|
||||
fe_spectral_inversion_t inversion;
|
||||
union {
|
||||
struct dvb_qpsk_parameters qpsk;
|
||||
struct dvb_qam_parameters qam;
|
||||
struct dvb_ofdm_parameters ofdm;
|
||||
struct dvb_vsb_parameters vsb;
|
||||
} u;
|
||||
};
|
||||
|
||||
|
||||
struct dvb_frontend_event {
|
||||
fe_status_t status;
|
||||
struct dvb_frontend_parameters parameters;
|
||||
};
|
||||
|
||||
/* S2API Commands */
|
||||
#define DTV_UNDEFINED 0
|
||||
#define DTV_TUNE 1
|
||||
#define DTV_CLEAR 2
|
||||
#define DTV_FREQUENCY 3
|
||||
#define DTV_MODULATION 4
|
||||
#define DTV_BANDWIDTH_HZ 5
|
||||
#define DTV_INVERSION 6
|
||||
#define DTV_DISEQC_MASTER 7
|
||||
#define DTV_SYMBOL_RATE 8
|
||||
#define DTV_INNER_FEC 9
|
||||
#define DTV_VOLTAGE 10
|
||||
#define DTV_TONE 11
|
||||
#define DTV_PILOT 12
|
||||
#define DTV_ROLLOFF 13
|
||||
#define DTV_DISEQC_SLAVE_REPLY 14
|
||||
|
||||
/* Basic enumeration set for querying unlimited capabilities */
|
||||
#define DTV_FE_CAPABILITY_COUNT 15
|
||||
#define DTV_FE_CAPABILITY 16
|
||||
#define DTV_DELIVERY_SYSTEM 17
|
||||
|
||||
/* ISDB-T and ISDB-Tsb */
|
||||
#define DTV_ISDBT_PARTIAL_RECEPTION 18
|
||||
#define DTV_ISDBT_SOUND_BROADCASTING 19
|
||||
|
||||
#define DTV_ISDBT_SB_SUBCHANNEL_ID 20
|
||||
#define DTV_ISDBT_SB_SEGMENT_IDX 21
|
||||
#define DTV_ISDBT_SB_SEGMENT_COUNT 22
|
||||
|
||||
#define DTV_ISDBT_LAYERA_FEC 23
|
||||
#define DTV_ISDBT_LAYERA_MODULATION 24
|
||||
#define DTV_ISDBT_LAYERA_SEGMENT_COUNT 25
|
||||
#define DTV_ISDBT_LAYERA_TIME_INTERLEAVING 26
|
||||
|
||||
#define DTV_ISDBT_LAYERB_FEC 27
|
||||
#define DTV_ISDBT_LAYERB_MODULATION 28
|
||||
#define DTV_ISDBT_LAYERB_SEGMENT_COUNT 29
|
||||
#define DTV_ISDBT_LAYERB_TIME_INTERLEAVING 30
|
||||
|
||||
#define DTV_ISDBT_LAYERC_FEC 31
|
||||
#define DTV_ISDBT_LAYERC_MODULATION 32
|
||||
#define DTV_ISDBT_LAYERC_SEGMENT_COUNT 33
|
||||
#define DTV_ISDBT_LAYERC_TIME_INTERLEAVING 34
|
||||
|
||||
#define DTV_API_VERSION 35
|
||||
|
||||
#define DTV_CODE_RATE_HP 36
|
||||
#define DTV_CODE_RATE_LP 37
|
||||
#define DTV_GUARD_INTERVAL 38
|
||||
#define DTV_TRANSMISSION_MODE 39
|
||||
#define DTV_HIERARCHY 40
|
||||
|
||||
#define DTV_ISDBT_LAYER_ENABLED 41
|
||||
|
||||
#define DTV_ISDBS_TS_ID 42
|
||||
|
||||
#define DTV_MAX_COMMAND DTV_ISDBS_TS_ID
|
||||
|
||||
typedef enum fe_pilot {
|
||||
PILOT_ON,
|
||||
PILOT_OFF,
|
||||
PILOT_AUTO,
|
||||
} fe_pilot_t;
|
||||
|
||||
typedef enum fe_rolloff {
|
||||
ROLLOFF_35, /* Implied value in DVB-S, default for DVB-S2 */
|
||||
ROLLOFF_20,
|
||||
ROLLOFF_25,
|
||||
ROLLOFF_AUTO,
|
||||
} fe_rolloff_t;
|
||||
|
||||
typedef enum fe_delivery_system {
|
||||
SYS_UNDEFINED,
|
||||
SYS_DVBC_ANNEX_AC,
|
||||
SYS_DVBC_ANNEX_B,
|
||||
SYS_DVBT,
|
||||
SYS_DSS,
|
||||
SYS_DVBS,
|
||||
SYS_DVBS2,
|
||||
SYS_DVBH,
|
||||
SYS_ISDBT,
|
||||
SYS_ISDBS,
|
||||
SYS_ISDBC,
|
||||
SYS_ATSC,
|
||||
SYS_ATSCMH,
|
||||
SYS_DMBTH,
|
||||
SYS_CMMB,
|
||||
SYS_DAB,
|
||||
} fe_delivery_system_t;
|
||||
|
||||
struct dtv_cmds_h {
|
||||
char *name; /* A display name for debugging purposes */
|
||||
|
||||
__u32 cmd; /* A unique ID */
|
||||
|
||||
/* Flags */
|
||||
__u32 set:1; /* Either a set or get property */
|
||||
__u32 buffer:1; /* Does this property use the buffer? */
|
||||
__u32 reserved:30; /* Align */
|
||||
};
|
||||
|
||||
struct dtv_property {
|
||||
__u32 cmd;
|
||||
__u32 reserved[3];
|
||||
union {
|
||||
__u32 data;
|
||||
struct {
|
||||
__u8 data[32];
|
||||
__u32 len;
|
||||
__u32 reserved1[3];
|
||||
void *reserved2;
|
||||
} buffer;
|
||||
} u;
|
||||
int result;
|
||||
} __attribute__ ((packed));
|
||||
|
||||
/* num of properties cannot exceed DTV_IOCTL_MAX_MSGS per ioctl */
|
||||
#define DTV_IOCTL_MAX_MSGS 64
|
||||
|
||||
struct dtv_properties {
|
||||
__u32 num;
|
||||
struct dtv_property *props;
|
||||
};
|
||||
|
||||
#define <link linkend="FE_GET_PROPERTY">FE_SET_PROPERTY</link> _IOW('o', 82, struct dtv_properties)
|
||||
#define <link linkend="FE_GET_PROPERTY">FE_GET_PROPERTY</link> _IOR('o', 83, struct dtv_properties)
|
||||
|
||||
|
||||
/**
|
||||
* When set, this flag will disable any zigzagging or other "normal" tuning
|
||||
* behaviour. Additionally, there will be no automatic monitoring of the lock
|
||||
* status, and hence no frontend events will be generated. If a frontend device
|
||||
* is closed, this flag will be automatically turned off when the device is
|
||||
* reopened read-write.
|
||||
*/
|
||||
#define FE_TUNE_MODE_ONESHOT 0x01
|
||||
|
||||
|
||||
#define <link linkend="FE_GET_INFO">FE_GET_INFO</link> _IOR('o', 61, struct dvb_frontend_info)
|
||||
|
||||
#define <link linkend="FE_DISEQC_RESET_OVERLOAD">FE_DISEQC_RESET_OVERLOAD</link> _IO('o', 62)
|
||||
#define <link linkend="FE_DISEQC_SEND_MASTER_CMD">FE_DISEQC_SEND_MASTER_CMD</link> _IOW('o', 63, struct dvb_diseqc_master_cmd)
|
||||
#define <link linkend="FE_DISEQC_RECV_SLAVE_REPLY">FE_DISEQC_RECV_SLAVE_REPLY</link> _IOR('o', 64, struct dvb_diseqc_slave_reply)
|
||||
#define <link linkend="FE_DISEQC_SEND_BURST">FE_DISEQC_SEND_BURST</link> _IO('o', 65) /* fe_sec_mini_cmd_t */
|
||||
|
||||
#define <link linkend="FE_SET_TONE">FE_SET_TONE</link> _IO('o', 66) /* fe_sec_tone_mode_t */
|
||||
#define <link linkend="FE_SET_VOLTAGE">FE_SET_VOLTAGE</link> _IO('o', 67) /* fe_sec_voltage_t */
|
||||
#define <link linkend="FE_ENABLE_HIGH_LNB_VOLTAGE">FE_ENABLE_HIGH_LNB_VOLTAGE</link> _IO('o', 68) /* int */
|
||||
|
||||
#define <link linkend="FE_READ_STATUS">FE_READ_STATUS</link> _IOR('o', 69, fe_status_t)
|
||||
#define <link linkend="FE_READ_BER">FE_READ_BER</link> _IOR('o', 70, __u32)
|
||||
#define <link linkend="FE_READ_SIGNAL_STRENGTH">FE_READ_SIGNAL_STRENGTH</link> _IOR('o', 71, __u16)
|
||||
#define <link linkend="FE_READ_SNR">FE_READ_SNR</link> _IOR('o', 72, __u16)
|
||||
#define <link linkend="FE_READ_UNCORRECTED_BLOCKS">FE_READ_UNCORRECTED_BLOCKS</link> _IOR('o', 73, __u32)
|
||||
|
||||
#define <link linkend="FE_SET_FRONTEND">FE_SET_FRONTEND</link> _IOW('o', 76, struct dvb_frontend_parameters)
|
||||
#define <link linkend="FE_GET_FRONTEND">FE_GET_FRONTEND</link> _IOR('o', 77, struct dvb_frontend_parameters)
|
||||
#define <link linkend="FE_SET_FRONTEND_TUNE_MODE">FE_SET_FRONTEND_TUNE_MODE</link> _IO('o', 81) /* unsigned int */
|
||||
#define <link linkend="FE_GET_EVENT">FE_GET_EVENT</link> _IOR('o', 78, struct dvb_frontend_event)
|
||||
|
||||
#define <link linkend="FE_DISHNETWORK_SEND_LEGACY_CMD">FE_DISHNETWORK_SEND_LEGACY_CMD</link> _IO('o', 80) /* unsigned int */
|
||||
|
||||
#endif /*_DVBFRONTEND_H_*/
|
||||
</programlisting>
|
||||
|
|
@ -73,7 +73,8 @@ a specific frontend type.</para>
|
|||
<section id="frontend_info">
|
||||
<title>frontend information</title>
|
||||
|
||||
<para>Information about the frontend ca be queried with FE_GET_INFO.</para>
|
||||
<para>Information about the frontend ca be queried with
|
||||
<link linkend="FE_GET_INFO">FE_GET_INFO</link>.</para>
|
||||
|
||||
<programlisting>
|
||||
struct dvb_frontend_info {
|
||||
|
|
@ -338,7 +339,7 @@ modulation mode which can be one of the following:
|
|||
<entry align="char">
|
||||
<para>This system call opens a named frontend device (/dev/dvb/adapter0/frontend0)
|
||||
for subsequent use. Usually the first thing to do after a successful open is to
|
||||
find out the frontend type with FE_GET_INFO.</para>
|
||||
find out the frontend type with <link linkend="FE_GET_INFO">FE_GET_INFO</link>.</para>
|
||||
<para>The device can be opened in read-only mode, which only allows monitoring of
|
||||
device status and statistics, or read/write mode, which allows any kind of use
|
||||
(e.g. performing tuning operations.)
|
||||
|
|
@ -478,7 +479,7 @@ modulation mode which can be one of the following:
|
|||
</row></tbody></tgroup></informaltable>
|
||||
</section>
|
||||
|
||||
<section id="frontend_read_status">
|
||||
<section id="FE_READ_STATUS">
|
||||
<title>FE_READ_STATUS</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
|
|
@ -492,7 +493,7 @@ modulation mode which can be one of the following:
|
|||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(int fd, int request = FE_READ_STATUS,
|
||||
<para>int ioctl(int fd, int request = <link linkend="FE_READ_STATUS">FE_READ_STATUS</link>,
|
||||
fe_status_t ⋆status);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
|
|
@ -511,7 +512,7 @@ modulation mode which can be one of the following:
|
|||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals FE_READ_STATUS for this command.</para>
|
||||
<para>Equals <link linkend="FE_READ_STATUS">FE_READ_STATUS</link> for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
|
|
@ -542,7 +543,7 @@ modulation mode which can be one of the following:
|
|||
</row></tbody></tgroup></informaltable>
|
||||
</section>
|
||||
|
||||
<section id="frontend_read_ber">
|
||||
<section id="FE_READ_BER">
|
||||
<title>FE_READ_BER</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
|
|
@ -557,7 +558,7 @@ modulation mode which can be one of the following:
|
|||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(int fd, int request = FE_READ_BER,
|
||||
<para>int ioctl(int fd, int request = <link linkend="FE_READ_BER">FE_READ_BER</link>,
|
||||
uint32_t ⋆ber);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
|
|
@ -575,7 +576,7 @@ modulation mode which can be one of the following:
|
|||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals FE_READ_BER for this command.</para>
|
||||
<para>Equals <link linkend="FE_READ_BER">FE_READ_BER</link> for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
|
|
@ -619,7 +620,7 @@ modulation mode which can be one of the following:
|
|||
</row></tbody></tgroup></informaltable>
|
||||
</section>
|
||||
|
||||
<section id="frontend_read_snr">
|
||||
<section id="FE_READ_SNR">
|
||||
<title>FE_READ_SNR</title>
|
||||
|
||||
<para>DESCRIPTION
|
||||
|
|
@ -634,7 +635,7 @@ modulation mode which can be one of the following:
|
|||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(int fd, int request = FE_READ_SNR, int16_t
|
||||
<para>int ioctl(int fd, int request = <link linkend="FE_READ_SNR">FE_READ_SNR</link>, int16_t
|
||||
⋆snr);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
|
|
@ -652,7 +653,7 @@ modulation mode which can be one of the following:
|
|||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals FE_READ_SNR for this command.</para>
|
||||
<para>Equals <link linkend="FE_READ_SNR">FE_READ_SNR</link> for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
|
|
@ -697,7 +698,7 @@ modulation mode which can be one of the following:
|
|||
</row></tbody></tgroup></informaltable>
|
||||
</section>
|
||||
|
||||
<section id="frontend_read_signal_strength">
|
||||
<section id="FE_READ_SIGNAL_STRENGTH">
|
||||
<title>FE_READ_SIGNAL_STRENGTH</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
|
|
@ -712,7 +713,7 @@ modulation mode which can be one of the following:
|
|||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl( int fd, int request =
|
||||
FE_READ_SIGNAL_STRENGTH, int16_t ⋆strength);</para>
|
||||
<link linkend="FE_READ_SIGNAL_STRENGTH">FE_READ_SIGNAL_STRENGTH</link>, int16_t ⋆strength);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
|
||||
|
|
@ -730,7 +731,7 @@ modulation mode which can be one of the following:
|
|||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals FE_READ_SIGNAL_STRENGTH for this
|
||||
<para>Equals <link linkend="FE_READ_SIGNAL_STRENGTH">FE_READ_SIGNAL_STRENGTH</link> for this
|
||||
command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
|
|
@ -775,7 +776,7 @@ modulation mode which can be one of the following:
|
|||
</row></tbody></tgroup></informaltable>
|
||||
</section>
|
||||
|
||||
<section id="frontend_read_ub">
|
||||
<section id="FE_READ_UNCORRECTED_BLOCKS">
|
||||
<title>FE_READ_UNCORRECTED_BLOCKS</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
|
|
@ -797,7 +798,7 @@ modulation mode which can be one of the following:
|
|||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl( int fd, int request =
|
||||
FE_READ_UNCORRECTED_BLOCKS, uint32_t ⋆ublocks);</para>
|
||||
<link linkend="FE_READ_UNCORRECTED_BLOCKS">FE_READ_UNCORRECTED_BLOCKS</link>, uint32_t ⋆ublocks);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
|
|
@ -814,7 +815,7 @@ modulation mode which can be one of the following:
|
|||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals FE_READ_UNCORRECTED_BLOCKS for this
|
||||
<para>Equals <link linkend="FE_READ_UNCORRECTED_BLOCKS">FE_READ_UNCORRECTED_BLOCKS</link> for this
|
||||
command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
|
|
@ -852,7 +853,7 @@ modulation mode which can be one of the following:
|
|||
</row></tbody></tgroup></informaltable>
|
||||
</section>
|
||||
|
||||
<section id="frontend_set_fe">
|
||||
<section id="FE_SET_FRONTEND">
|
||||
<title>FE_SET_FRONTEND</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
|
|
@ -861,8 +862,8 @@ modulation mode which can be one of the following:
|
|||
<para>This ioctl call starts a tuning operation using specified parameters. The result
|
||||
of this call will be successful if the parameters were valid and the tuning could
|
||||
be initiated. The result of the tuning operation in itself, however, will arrive
|
||||
asynchronously as an event (see documentation for FE_GET_EVENT and
|
||||
FrontendEvent.) If a new FE_SET_FRONTEND operation is initiated before
|
||||
asynchronously as an event (see documentation for <link linkend="FE_GET_EVENT">FE_GET_EVENT</link> and
|
||||
FrontendEvent.) If a new <link linkend="FE_SET_FRONTEND">FE_SET_FRONTEND</link> operation is initiated before
|
||||
the previous one was completed, the previous operation will be aborted in favor
|
||||
of the new one. This command requires read/write access to the device.</para>
|
||||
</entry>
|
||||
|
|
@ -872,7 +873,7 @@ modulation mode which can be one of the following:
|
|||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(int fd, int request = FE_SET_FRONTEND,
|
||||
<para>int ioctl(int fd, int request = <link linkend="FE_SET_FRONTEND">FE_SET_FRONTEND</link>,
|
||||
struct dvb_frontend_parameters ⋆p);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
|
|
@ -890,7 +891,7 @@ modulation mode which can be one of the following:
|
|||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals FE_SET_FRONTEND for this command.</para>
|
||||
<para>Equals <link linkend="FE_SET_FRONTEND">FE_SET_FRONTEND</link> for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
|
|
@ -928,7 +929,7 @@ modulation mode which can be one of the following:
|
|||
</row></tbody></tgroup></informaltable>
|
||||
</section>
|
||||
|
||||
<section id="frontend_get_fe">
|
||||
<section id="FE_GET_FRONTEND">
|
||||
<title>FE_GET_FRONTEND</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
|
|
@ -943,7 +944,7 @@ modulation mode which can be one of the following:
|
|||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(int fd, int request = FE_GET_FRONTEND,
|
||||
<para>int ioctl(int fd, int request = <link linkend="FE_GET_FRONTEND">FE_GET_FRONTEND</link>,
|
||||
struct dvb_frontend_parameters ⋆p);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
|
|
@ -962,7 +963,7 @@ modulation mode which can be one of the following:
|
|||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals FE_SET_FRONTEND for this command.</para>
|
||||
<para>Equals <link linkend="FE_SET_FRONTEND">FE_SET_FRONTEND</link> for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
|
|
@ -1003,7 +1004,7 @@ modulation mode which can be one of the following:
|
|||
|
||||
</section>
|
||||
|
||||
<section id="frontend_get_event">
|
||||
<section id="FE_GET_EVENT">
|
||||
<title>FE_GET_EVENT</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
|
|
@ -1024,7 +1025,8 @@ modulation mode which can be one of the following:
|
|||
rather small (room for 8 events), the queue must be serviced regularly to avoid
|
||||
overflow. If an overflow happens, the oldest event is discarded from the queue,
|
||||
and an error (EOVERFLOW) occurs the next time the queue is read. After
|
||||
reporting the error condition in this fashion, subsequent FE_GET_EVENT
|
||||
reporting the error condition in this fashion, subsequent
|
||||
<link linkend="FE_GET_EVENT">FE_GET_EVENT</link>
|
||||
calls will return events from the queue as usual.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
|
|
@ -1057,7 +1059,7 @@ modulation mode which can be one of the following:
|
|||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals FE_GET_EVENT for this command.</para>
|
||||
<para>Equals <link linkend="FE_GET_EVENT">FE_GET_EVENT</link> for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
|
|
@ -1115,7 +1117,7 @@ modulation mode which can be one of the following:
|
|||
</row></tbody></tgroup></informaltable>
|
||||
</section>
|
||||
|
||||
<section id="frontend_get_info">
|
||||
<section id="FE_GET_INFO">
|
||||
<title>FE_GET_INFO</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
|
|
@ -1130,7 +1132,7 @@ modulation mode which can be one of the following:
|
|||
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para> int ioctl(int fd, int request = FE_GET_INFO, struct
|
||||
<para> int ioctl(int fd, int request = <link linkend="FE_GET_INFO">FE_GET_INFO</link>, struct
|
||||
dvb_frontend_info ⋆info);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
|
|
@ -1149,7 +1151,7 @@ modulation mode which can be one of the following:
|
|||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals FE_GET_INFO for this command.</para>
|
||||
<para>Equals <link linkend="FE_GET_INFO">FE_GET_INFO</link> for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
|
|
@ -1181,7 +1183,7 @@ modulation mode which can be one of the following:
|
|||
</row></tbody></tgroup></informaltable>
|
||||
</section>
|
||||
|
||||
<section id="frontend_diseqc_reset_overload">
|
||||
<section id="FE_DISEQC_RESET_OVERLOAD">
|
||||
<title>FE_DISEQC_RESET_OVERLOAD</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
|
|
@ -1199,7 +1201,7 @@ modulation mode which can be one of the following:
|
|||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(int fd, int request =
|
||||
FE_DISEQC_RESET_OVERLOAD);</para>
|
||||
<link linkend="FE_DISEQC_RESET_OVERLOAD">FE_DISEQC_RESET_OVERLOAD</link>);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
<para>PARAMETERS
|
||||
|
|
@ -1216,7 +1218,7 @@ modulation mode which can be one of the following:
|
|||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals FE_DISEQC_RESET_OVERLOAD for this
|
||||
<para>Equals <link linkend="FE_DISEQC_RESET_OVERLOAD">FE_DISEQC_RESET_OVERLOAD</link> for this
|
||||
command.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
|
|
@ -1247,7 +1249,7 @@ modulation mode which can be one of the following:
|
|||
</row></tbody></tgroup></informaltable>
|
||||
</section>
|
||||
|
||||
<section id="frontend_diseqc_send_master_cmd">
|
||||
<section id="FE_DISEQC_SEND_MASTER_CMD">
|
||||
<title>FE_DISEQC_SEND_MASTER_CMD</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
|
|
@ -1261,7 +1263,7 @@ modulation mode which can be one of the following:
|
|||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(int fd, int request =
|
||||
FE_DISEQC_SEND_MASTER_CMD, struct
|
||||
<link linkend="FE_DISEQC_SEND_MASTER_CMD">FE_DISEQC_SEND_MASTER_CMD</link>, struct
|
||||
dvb_diseqc_master_cmd ⋆cmd);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
|
|
@ -1280,7 +1282,7 @@ modulation mode which can be one of the following:
|
|||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals FE_DISEQC_SEND_MASTER_CMD for this
|
||||
<para>Equals <link linkend="FE_DISEQC_SEND_MASTER_CMD">FE_DISEQC_SEND_MASTER_CMD</link> for this
|
||||
command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
|
|
@ -1335,7 +1337,7 @@ modulation mode which can be one of the following:
|
|||
</row></tbody></tgroup></informaltable>
|
||||
</section>
|
||||
|
||||
<section id="frontend_diseqc_recv_slave_reply">
|
||||
<section id="FE_DISEQC_RECV_SLAVE_REPLY">
|
||||
<title>FE_DISEQC_RECV_SLAVE_REPLY</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
|
|
@ -1350,7 +1352,7 @@ modulation mode which can be one of the following:
|
|||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(int fd, int request =
|
||||
FE_DISEQC_RECV_SLAVE_REPLY, struct
|
||||
<link linkend="FE_DISEQC_RECV_SLAVE_REPLY">FE_DISEQC_RECV_SLAVE_REPLY</link>, struct
|
||||
dvb_diseqc_slave_reply ⋆reply);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
|
|
@ -1369,7 +1371,7 @@ modulation mode which can be one of the following:
|
|||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals FE_DISEQC_RECV_SLAVE_REPLY for this
|
||||
<para>Equals <link linkend="FE_DISEQC_RECV_SLAVE_REPLY">FE_DISEQC_RECV_SLAVE_REPLY</link> for this
|
||||
command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
|
|
@ -1423,7 +1425,7 @@ modulation mode which can be one of the following:
|
|||
</row></tbody></tgroup></informaltable>
|
||||
</section>
|
||||
|
||||
<section id="frontend_diseqc_send_burst">
|
||||
<section id="FE_DISEQC_SEND_BURST">
|
||||
<title>FE_DISEQC_SEND_BURST</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
|
|
@ -1438,7 +1440,7 @@ modulation mode which can be one of the following:
|
|||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(int fd, int request =
|
||||
FE_DISEQC_SEND_BURST, fe_sec_mini_cmd_t burst);</para>
|
||||
<link linkend="FE_DISEQC_SEND_BURST">FE_DISEQC_SEND_BURST</link>, fe_sec_mini_cmd_t burst);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
|
||||
|
|
@ -1456,7 +1458,7 @@ modulation mode which can be one of the following:
|
|||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals FE_DISEQC_SEND_BURST for this command.</para>
|
||||
<para>Equals <link linkend="FE_DISEQC_SEND_BURST">FE_DISEQC_SEND_BURST</link> for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
|
|
@ -1509,7 +1511,7 @@ modulation mode which can be one of the following:
|
|||
</row></tbody></tgroup></informaltable>
|
||||
</section>
|
||||
|
||||
<section id="frontend_set_tone">
|
||||
<section id="FE_SET_TONE">
|
||||
<title>FE_SET_TONE</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
|
|
@ -1523,7 +1525,7 @@ modulation mode which can be one of the following:
|
|||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(int fd, int request = FE_SET_TONE,
|
||||
<para>int ioctl(int fd, int request = <link linkend="FE_SET_TONE">FE_SET_TONE</link>,
|
||||
fe_sec_tone_mode_t tone);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
|
|
@ -1541,7 +1543,7 @@ modulation mode which can be one of the following:
|
|||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals FE_SET_TONE for this command.</para>
|
||||
<para>Equals <link linkend="FE_SET_TONE">FE_SET_TONE</link> for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
|
|
@ -1592,7 +1594,7 @@ modulation mode which can be one of the following:
|
|||
</row></tbody></tgroup></informaltable>
|
||||
</section>
|
||||
|
||||
<section id="fe_set_voltage">
|
||||
<section id="FE_SET_VOLTAGE">
|
||||
<title>FE_SET_VOLTAGE</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
|
|
@ -1606,7 +1608,7 @@ modulation mode which can be one of the following:
|
|||
</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(int fd, int request = FE_SET_VOLTAGE,
|
||||
<para>int ioctl(int fd, int request = <link linkend="FE_SET_VOLTAGE">FE_SET_VOLTAGE</link>,
|
||||
fe_sec_voltage_t voltage);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
|
|
@ -1625,7 +1627,7 @@ modulation mode which can be one of the following:
|
|||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals FE_SET_VOLTAGE for this command.</para>
|
||||
<para>Equals <link linkend="FE_SET_VOLTAGE">FE_SET_VOLTAGE</link> for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
|
|
@ -1677,7 +1679,7 @@ modulation mode which can be one of the following:
|
|||
</row></tbody></tgroup></informaltable>
|
||||
</section>
|
||||
|
||||
<section id="frontend_enable_high_lnb_volt">
|
||||
<section id="FE_ENABLE_HIGH_LNB_VOLTAGE">
|
||||
<title>FE_ENABLE_HIGH_LNB_VOLTAGE</title>
|
||||
<para>DESCRIPTION
|
||||
</para>
|
||||
|
|
@ -1694,7 +1696,7 @@ modulation mode which can be one of the following:
|
|||
<informaltable><tgroup cols="1"><tbody><row><entry
|
||||
align="char">
|
||||
<para>int ioctl(int fd, int request =
|
||||
FE_ENABLE_HIGH_LNB_VOLTAGE, int high);</para>
|
||||
<link linkend="FE_ENABLE_HIGH_LNB_VOLTAGE">FE_ENABLE_HIGH_LNB_VOLTAGE</link>, int high);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
|
||||
|
|
@ -1712,7 +1714,7 @@ modulation mode which can be one of the following:
|
|||
<para>int request</para>
|
||||
</entry><entry
|
||||
align="char">
|
||||
<para>Equals FE_SET_VOLTAGE for this command.</para>
|
||||
<para>Equals <link linkend="FE_SET_VOLTAGE">FE_SET_VOLTAGE</link> for this command.</para>
|
||||
</entry>
|
||||
</row><row><entry
|
||||
align="char">
|
||||
|
|
@ -1762,5 +1764,82 @@ modulation mode which can be one of the following:
|
|||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
</section>
|
||||
|
||||
<section id="FE_SET_FRONTEND_TUNE_MODE">
|
||||
<title>FE_SET_FRONTEND_TUNE_MODE</title>
|
||||
<para>DESCRIPTION</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row>
|
||||
<entry align="char">
|
||||
<para>Allow setting tuner mode flags to the frontend.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
|
||||
<para>SYNOPSIS</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row>
|
||||
<entry align="char">
|
||||
<para>int ioctl(int fd, int request =
|
||||
<link linkend="FE_SET_FRONTEND_TUNE_MODE">FE_SET_FRONTEND_TUNE_MODE</link>, unsigned int flags);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
|
||||
<para>PARAMETERS</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row>
|
||||
<entry align="char">
|
||||
<para>unsigned int flags</para>
|
||||
</entry>
|
||||
<entry align="char">
|
||||
<para>
|
||||
FE_TUNE_MODE_ONESHOT When set, this flag will disable any zigzagging or other "normal" tuning behaviour. Additionally, there will be no automatic monitoring of the lock status, and hence no frontend events will be generated. If a frontend device is closed, this flag will be automatically turned off when the device is reopened read-write.
|
||||
</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
|
||||
<para>ERRORS</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row>
|
||||
<entry align="char"><para>EINVAL</para></entry>
|
||||
<entry align="char"><para>Invalid argument.</para></entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
</section>
|
||||
&sub-isdbt;
|
||||
|
||||
<section id="FE_DISHNETWORK_SEND_LEGACY_CMD">
|
||||
<title>FE_DISHNETWORK_SEND_LEGACY_CMD</title>
|
||||
<para>DESCRIPTION</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row>
|
||||
<entry align="char">
|
||||
<para>WARNING: This is a very obscure legacy command, used only at stv0299 driver. Should not be used on newer drivers.</para>
|
||||
<para>It provides a non-standard method for selecting Diseqc voltage on the frontend, for Dish Network legacy switches.</para>
|
||||
<para>As support for this ioctl were added in 2004, this means that such dishes were already legacy in 2004.</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
|
||||
<para>SYNOPSIS</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row>
|
||||
<entry align="char">
|
||||
<para>int ioctl(int fd, int request =
|
||||
<link linkend="FE_DISHNETWORK_SEND_LEGACY_CMD">FE_DISHNETWORK_SEND_LEGACY_CMD</link>, unsigned long cmd);</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
|
||||
<para>PARAMETERS</para>
|
||||
<informaltable><tgroup cols="2"><tbody><row>
|
||||
<entry align="char">
|
||||
<para>unsigned long cmd</para>
|
||||
</entry>
|
||||
<entry align="char">
|
||||
<para>
|
||||
sends the specified raw cmd to the dish via DISEqC.
|
||||
</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
|
||||
<para>ERRORS</para>
|
||||
<informaltable><tgroup cols="1"><tbody><row>
|
||||
<entry align="char">
|
||||
<para>There are no errors in use for this call</para>
|
||||
</entry>
|
||||
</row></tbody></tgroup></informaltable>
|
||||
</section>
|
||||
|
||||
</section>
|
||||
|
||||
&sub-dvbproperty;
|
||||
|
|
|
|||
|
|
@ -417,8 +417,8 @@ desc->chip->end();
|
|||
</para>
|
||||
<para>
|
||||
To make use of the split implementation, replace the call to
|
||||
__do_IRQ by a call to desc->chip->handle_irq() and associate
|
||||
the appropriate handler function to desc->chip->handle_irq().
|
||||
__do_IRQ by a call to desc->handle_irq() and associate
|
||||
the appropriate handler function to desc->handle_irq().
|
||||
In most cases the generic handler implementations should
|
||||
be sufficient.
|
||||
</para>
|
||||
|
|
|
|||
|
|
@ -352,7 +352,7 @@ asmlinkage long sys_mycall(int arg)
|
|||
</para>
|
||||
|
||||
<programlisting>
|
||||
if (signal_pending())
|
||||
if (signal_pending(current))
|
||||
return -ERESTARTSYS;
|
||||
</programlisting>
|
||||
|
||||
|
|
|
|||
|
|
@ -280,7 +280,7 @@
|
|||
<!ENTITY sub-v4l2 SYSTEM "v4l/v4l2.xml">
|
||||
<!ENTITY sub-intro SYSTEM "dvb/intro.xml">
|
||||
<!ENTITY sub-frontend SYSTEM "dvb/frontend.xml">
|
||||
<!ENTITY sub-isdbt SYSTEM "dvb/isdbt.xml">
|
||||
<!ENTITY sub-dvbproperty SYSTEM "dvb/dvbproperty.xml">
|
||||
<!ENTITY sub-demux SYSTEM "dvb/demux.xml">
|
||||
<!ENTITY sub-video SYSTEM "dvb/video.xml">
|
||||
<!ENTITY sub-audio SYSTEM "dvb/audio.xml">
|
||||
|
|
@ -288,6 +288,7 @@
|
|||
<!ENTITY sub-net SYSTEM "dvb/net.xml">
|
||||
<!ENTITY sub-kdapi SYSTEM "dvb/kdapi.xml">
|
||||
<!ENTITY sub-examples SYSTEM "dvb/examples.xml">
|
||||
<!ENTITY sub-frontend-h SYSTEM "dvb/frontend.h.xml">
|
||||
<!ENTITY sub-dvbapi SYSTEM "dvb/dvbapi.xml">
|
||||
<!ENTITY sub-media SYSTEM "media.xml">
|
||||
<!ENTITY sub-media-entities SYSTEM "media-entities.tmpl">
|
||||
|
|
|
|||
|
|
@ -362,7 +362,7 @@ module_exit(board_cleanup);
|
|||
<sect1 id="Multiple_chip_control">
|
||||
<title>Multiple chip control</title>
|
||||
<para>
|
||||
The nand driver can control chip arrays. Therefor the
|
||||
The nand driver can control chip arrays. Therefore the
|
||||
board driver must provide an own select_chip function. This
|
||||
function must (de)select the requested chip.
|
||||
The function pointer in the nand_chip structure must
|
||||
|
|
|
|||
|
|
@ -86,4 +86,9 @@
|
|||
!Iinclude/trace/events/irq.h
|
||||
</chapter>
|
||||
|
||||
<chapter id="signal">
|
||||
<title>SIGNAL</title>
|
||||
!Iinclude/trace/events/signal.h
|
||||
</chapter>
|
||||
|
||||
</book>
|
||||
|
|
|
|||
|
|
@ -280,11 +280,29 @@ minimum value disables backlight compensation.</entry>
|
|||
<constant>V4L2_COLORFX_BW</constant> (1) and
|
||||
<constant>V4L2_COLORFX_SEPIA</constant> (2).</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CID_ROTATE</constant></entry>
|
||||
<entry>integer</entry>
|
||||
<entry>Rotates the image by specified angle. Common angles are 90,
|
||||
270 and 180. Rotating the image to 90 and 270 will reverse the height
|
||||
and width of the display window. It is necessary to set the new height and
|
||||
width of the picture using the &VIDIOC-S-FMT; ioctl according to
|
||||
the rotation angle selected.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CID_BG_COLOR</constant></entry>
|
||||
<entry>integer</entry>
|
||||
<entry>Sets the background color on the current output device.
|
||||
Background color needs to be specified in the RGB24 format. The
|
||||
supplied 32 bit value is interpreted as bits 0-7 Red color information,
|
||||
bits 8-15 Green color information, bits 16-23 Blue color
|
||||
information and bits 24-31 must be zero.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CID_LASTP1</constant></entry>
|
||||
<entry></entry>
|
||||
<entry>End of the predefined control IDs (currently
|
||||
<constant>V4L2_CID_COLORFX</constant> + 1).</entry>
|
||||
<constant>V4L2_CID_BG_COLOR</constant> + 1).</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CID_PRIVATE_BASE</constant></entry>
|
||||
|
|
|
|||
|
|
@ -770,6 +770,11 @@ kernel sources in the file <filename>Documentation/video4linux/cx2341x/README.hm
|
|||
<entry>'S920'</entry>
|
||||
<entry>YUV 4:2:0 format of the gspca sn9c20x driver.</entry>
|
||||
</row>
|
||||
<row id="V4L2-PIX-FMT-STV0680">
|
||||
<entry><constant>V4L2_PIX_FMT_STV0680</constant></entry>
|
||||
<entry>'S680'</entry>
|
||||
<entry>Bayer format of the gspca stv0680 driver.</entry>
|
||||
</row>
|
||||
<row id="V4L2-PIX-FMT-WNVA">
|
||||
<entry><constant>V4L2_PIX_FMT_WNVA</constant></entry>
|
||||
<entry>'WNVA'</entry>
|
||||
|
|
|
|||
|
|
@ -363,6 +363,7 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> {
|
|||
#define <link linkend="V4L2-PIX-FMT-OV511">V4L2_PIX_FMT_OV511</link> v4l2_fourcc('O', '5', '1', '1') /* ov511 JPEG */
|
||||
#define <link linkend="V4L2-PIX-FMT-OV518">V4L2_PIX_FMT_OV518</link> v4l2_fourcc('O', '5', '1', '8') /* ov518 JPEG */
|
||||
#define <link linkend="V4L2-PIX-FMT-TM6000">V4L2_PIX_FMT_TM6000</link> v4l2_fourcc('T', 'M', '6', '0') /* tm5600/tm60x0 */
|
||||
#define <link linkend="V4L2-PIX-FMT-STV0680">V4L2_PIX_FMT_STV0680</link> v4l2_fourcc('S', '6', '8', '0') /* stv0680 bayer */
|
||||
|
||||
/*
|
||||
* F O R M A T E N U M E R A T I O N
|
||||
|
|
@ -492,7 +493,7 @@ struct <link linkend="v4l2-jpegcompression">v4l2_jpegcompression</link> {
|
|||
* you do, leave them untouched.
|
||||
* Inluding less markers will make the
|
||||
* resulting code smaller, but there will
|
||||
* be fewer aplications which can read it.
|
||||
* be fewer applications which can read it.
|
||||
* The presence of the APP and COM marker
|
||||
* is influenced by APP_len and COM_len
|
||||
* ONLY, not by this property! */
|
||||
|
|
@ -565,6 +566,7 @@ struct <link linkend="v4l2-framebuffer">v4l2_framebuffer</link> {
|
|||
#define V4L2_FBUF_CAP_LOCAL_ALPHA 0x0010
|
||||
#define V4L2_FBUF_CAP_GLOBAL_ALPHA 0x0020
|
||||
#define V4L2_FBUF_CAP_LOCAL_INV_ALPHA 0x0040
|
||||
#define V4L2_FBUF_CAP_SRC_CHROMAKEY 0x0080
|
||||
/* Flags for the 'flags' field. */
|
||||
#define V4L2_FBUF_FLAG_PRIMARY 0x0001
|
||||
#define V4L2_FBUF_FLAG_OVERLAY 0x0002
|
||||
|
|
@ -572,6 +574,7 @@ struct <link linkend="v4l2-framebuffer">v4l2_framebuffer</link> {
|
|||
#define V4L2_FBUF_FLAG_LOCAL_ALPHA 0x0008
|
||||
#define V4L2_FBUF_FLAG_GLOBAL_ALPHA 0x0010
|
||||
#define V4L2_FBUF_FLAG_LOCAL_INV_ALPHA 0x0020
|
||||
#define V4L2_FBUF_FLAG_SRC_CHROMAKEY 0x0040
|
||||
|
||||
struct <link linkend="v4l2-clip">v4l2_clip</link> {
|
||||
struct <link linkend="v4l2-rect">v4l2_rect</link> c;
|
||||
|
|
@ -914,8 +917,10 @@ enum <link linkend="v4l2-colorfx">v4l2_colorfx</link> {
|
|||
#define V4L2_CID_AUTOBRIGHTNESS (V4L2_CID_BASE+32)
|
||||
#define V4L2_CID_BAND_STOP_FILTER (V4L2_CID_BASE+33)
|
||||
|
||||
#define V4L2_CID_ROTATE (V4L2_CID_BASE+34)
|
||||
#define V4L2_CID_BG_COLOR (V4L2_CID_BASE+35)
|
||||
/* last CID + 1 */
|
||||
#define V4L2_CID_LASTP1 (V4L2_CID_BASE+34)
|
||||
#define V4L2_CID_LASTP1 (V4L2_CID_BASE+36)
|
||||
|
||||
/* MPEG-class control IDs defined by V4L2 */
|
||||
#define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900)
|
||||
|
|
|
|||
|
|
@ -336,6 +336,13 @@ alpha value. Alpha blending makes no sense for destructive overlays.</entry>
|
|||
inverted alpha channel of the framebuffer or VGA signal. Alpha
|
||||
blending makes no sense for destructive overlays.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_FBUF_CAP_SRC_CHROMAKEY</constant></entry>
|
||||
<entry>0x0080</entry>
|
||||
<entry>The device supports Source Chroma-keying. Framebuffer pixels
|
||||
with the chroma-key colors are replaced by video pixels, which is exactly opposite of
|
||||
<constant>V4L2_FBUF_CAP_CHROMAKEY</constant></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
|
@ -411,6 +418,16 @@ images, but with an inverted alpha value. The blend function is:
|
|||
output = framebuffer pixel * (1 - alpha) + video pixel * alpha. The
|
||||
actual alpha depth depends on the framebuffer pixel format.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_FBUF_FLAG_SRC_CHROMAKEY</constant></entry>
|
||||
<entry>0x0040</entry>
|
||||
<entry>Use source chroma-keying. The source chroma-key color is
|
||||
determined by the <structfield>chromakey</structfield> field of
|
||||
&v4l2-window; and negotiated with the &VIDIOC-S-FMT; ioctl, see <xref
|
||||
linkend="overlay" /> and <xref linkend="osd" />.
|
||||
Both chroma-keying are mutual exclusive to each other, so same
|
||||
<structfield>chromakey</structfield> field of &v4l2-window; is being used.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
|
|
|||
|
|
@ -5318,7 +5318,7 @@ struct _snd_pcm_runtime {
|
|||
pages of the given size and map them onto the virtually contiguous
|
||||
memory. The virtual pointer is addressed in runtime->dma_area.
|
||||
The physical address (runtime->dma_addr) is set to zero,
|
||||
because the buffer is physically non-contigous.
|
||||
because the buffer is physically non-contiguous.
|
||||
The physical address table is set up in sgbuf->table.
|
||||
You can get the physical address at a certain offset via
|
||||
<function>snd_pcm_sgbuf_get_addr()</function>.
|
||||
|
|
|
|||
|
|
@ -1,185 +1,10 @@
|
|||
CONFIG_RCU_TRACE debugfs Files and Formats
|
||||
|
||||
|
||||
The rcupreempt and rcutree implementations of RCU provide debugfs trace
|
||||
output that summarizes counters and state. This information is useful for
|
||||
debugging RCU itself, and can sometimes also help to debug abuses of RCU.
|
||||
Note that the rcuclassic implementation of RCU does not provide debugfs
|
||||
trace output.
|
||||
|
||||
The following sections describe the debugfs files and formats for
|
||||
preemptable RCU (rcupreempt) and hierarchical RCU (rcutree).
|
||||
|
||||
|
||||
Preemptable RCU debugfs Files and Formats
|
||||
|
||||
This implementation of RCU provides three debugfs files under the
|
||||
top-level directory RCU: rcu/rcuctrs (which displays the per-CPU
|
||||
counters used by preemptable RCU) rcu/rcugp (which displays grace-period
|
||||
counters), and rcu/rcustats (which internal counters for debugging RCU).
|
||||
|
||||
The output of "cat rcu/rcuctrs" looks as follows:
|
||||
|
||||
CPU last cur F M
|
||||
0 5 -5 0 0
|
||||
1 -1 0 0 0
|
||||
2 0 1 0 0
|
||||
3 0 1 0 0
|
||||
4 0 1 0 0
|
||||
5 0 1 0 0
|
||||
6 0 2 0 0
|
||||
7 0 -1 0 0
|
||||
8 0 1 0 0
|
||||
ggp = 26226, state = waitzero
|
||||
|
||||
The per-CPU fields are as follows:
|
||||
|
||||
o "CPU" gives the CPU number. Offline CPUs are not displayed.
|
||||
|
||||
o "last" gives the value of the counter that is being decremented
|
||||
for the current grace period phase. In the example above,
|
||||
the counters sum to 4, indicating that there are still four
|
||||
RCU read-side critical sections still running that started
|
||||
before the last counter flip.
|
||||
|
||||
o "cur" gives the value of the counter that is currently being
|
||||
both incremented (by rcu_read_lock()) and decremented (by
|
||||
rcu_read_unlock()). In the example above, the counters sum to
|
||||
1, indicating that there is only one RCU read-side critical section
|
||||
still running that started after the last counter flip.
|
||||
|
||||
o "F" indicates whether RCU is waiting for this CPU to acknowledge
|
||||
a counter flip. In the above example, RCU is not waiting on any,
|
||||
which is consistent with the state being "waitzero" rather than
|
||||
"waitack".
|
||||
|
||||
o "M" indicates whether RCU is waiting for this CPU to execute a
|
||||
memory barrier. In the above example, RCU is not waiting on any,
|
||||
which is consistent with the state being "waitzero" rather than
|
||||
"waitmb".
|
||||
|
||||
o "ggp" is the global grace-period counter.
|
||||
|
||||
o "state" is the RCU state, which can be one of the following:
|
||||
|
||||
o "idle": there is no grace period in progress.
|
||||
|
||||
o "waitack": RCU just incremented the global grace-period
|
||||
counter, which has the effect of reversing the roles of
|
||||
the "last" and "cur" counters above, and is waiting for
|
||||
all the CPUs to acknowledge the flip. Once the flip has
|
||||
been acknowledged, CPUs will no longer be incrementing
|
||||
what are now the "last" counters, so that their sum will
|
||||
decrease monotonically down to zero.
|
||||
|
||||
o "waitzero": RCU is waiting for the sum of the "last" counters
|
||||
to decrease to zero.
|
||||
|
||||
o "waitmb": RCU is waiting for each CPU to execute a memory
|
||||
barrier, which ensures that instructions from a given CPU's
|
||||
last RCU read-side critical section cannot be reordered
|
||||
with instructions following the memory-barrier instruction.
|
||||
|
||||
The output of "cat rcu/rcugp" looks as follows:
|
||||
|
||||
oldggp=48870 newggp=48873
|
||||
|
||||
Note that reading from this file provokes a synchronize_rcu(). The
|
||||
"oldggp" value is that of "ggp" from rcu/rcuctrs above, taken before
|
||||
executing the synchronize_rcu(), and the "newggp" value is also the
|
||||
"ggp" value, but taken after the synchronize_rcu() command returns.
|
||||
|
||||
|
||||
The output of "cat rcu/rcugp" looks as follows:
|
||||
|
||||
na=1337955 nl=40 wa=1337915 wl=44 da=1337871 dl=0 dr=1337871 di=1337871
|
||||
1=50989 e1=6138 i1=49722 ie1=82 g1=49640 a1=315203 ae1=265563 a2=49640
|
||||
z1=1401244 ze1=1351605 z2=49639 m1=5661253 me1=5611614 m2=49639
|
||||
|
||||
These are counters tracking internal preemptable-RCU events, however,
|
||||
some of them may be useful for debugging algorithms using RCU. In
|
||||
particular, the "nl", "wl", and "dl" values track the number of RCU
|
||||
callbacks in various states. The fields are as follows:
|
||||
|
||||
o "na" is the total number of RCU callbacks that have been enqueued
|
||||
since boot.
|
||||
|
||||
o "nl" is the number of RCU callbacks waiting for the previous
|
||||
grace period to end so that they can start waiting on the next
|
||||
grace period.
|
||||
|
||||
o "wa" is the total number of RCU callbacks that have started waiting
|
||||
for a grace period since boot. "na" should be roughly equal to
|
||||
"nl" plus "wa".
|
||||
|
||||
o "wl" is the number of RCU callbacks currently waiting for their
|
||||
grace period to end.
|
||||
|
||||
o "da" is the total number of RCU callbacks whose grace periods
|
||||
have completed since boot. "wa" should be roughly equal to
|
||||
"wl" plus "da".
|
||||
|
||||
o "dr" is the total number of RCU callbacks that have been removed
|
||||
from the list of callbacks ready to invoke. "dr" should be roughly
|
||||
equal to "da".
|
||||
|
||||
o "di" is the total number of RCU callbacks that have been invoked
|
||||
since boot. "di" should be roughly equal to "da", though some
|
||||
early versions of preemptable RCU had a bug so that only the
|
||||
last CPU's count of invocations was displayed, rather than the
|
||||
sum of all CPU's counts.
|
||||
|
||||
o "1" is the number of calls to rcu_try_flip(). This should be
|
||||
roughly equal to the sum of "e1", "i1", "a1", "z1", and "m1"
|
||||
described below. In other words, the number of times that
|
||||
the state machine is visited should be equal to the sum of the
|
||||
number of times that each state is visited plus the number of
|
||||
times that the state-machine lock acquisition failed.
|
||||
|
||||
o "e1" is the number of times that rcu_try_flip() was unable to
|
||||
acquire the fliplock.
|
||||
|
||||
o "i1" is the number of calls to rcu_try_flip_idle().
|
||||
|
||||
o "ie1" is the number of times rcu_try_flip_idle() exited early
|
||||
due to the calling CPU having no work for RCU.
|
||||
|
||||
o "g1" is the number of times that rcu_try_flip_idle() decided
|
||||
to start a new grace period. "i1" should be roughly equal to
|
||||
"ie1" plus "g1".
|
||||
|
||||
o "a1" is the number of calls to rcu_try_flip_waitack().
|
||||
|
||||
o "ae1" is the number of times that rcu_try_flip_waitack() found
|
||||
that at least one CPU had not yet acknowledge the new grace period
|
||||
(AKA "counter flip").
|
||||
|
||||
o "a2" is the number of time rcu_try_flip_waitack() found that
|
||||
all CPUs had acknowledged. "a1" should be roughly equal to
|
||||
"ae1" plus "a2". (This particular output was collected on
|
||||
a 128-CPU machine, hence the smaller-than-usual fraction of
|
||||
calls to rcu_try_flip_waitack() finding all CPUs having already
|
||||
acknowledged.)
|
||||
|
||||
o "z1" is the number of calls to rcu_try_flip_waitzero().
|
||||
|
||||
o "ze1" is the number of times that rcu_try_flip_waitzero() found
|
||||
that not all of the old RCU read-side critical sections had
|
||||
completed.
|
||||
|
||||
o "z2" is the number of times that rcu_try_flip_waitzero() finds
|
||||
the sum of the counters equal to zero, in other words, that
|
||||
all of the old RCU read-side critical sections had completed.
|
||||
The value of "z1" should be roughly equal to "ze1" plus
|
||||
"z2".
|
||||
|
||||
o "m1" is the number of calls to rcu_try_flip_waitmb().
|
||||
|
||||
o "me1" is the number of times that rcu_try_flip_waitmb() finds
|
||||
that at least one CPU has not yet executed a memory barrier.
|
||||
|
||||
o "m2" is the number of times that rcu_try_flip_waitmb() finds that
|
||||
all CPUs have executed a memory barrier.
|
||||
The rcutree implementation of RCU provides debugfs trace output that
|
||||
summarizes counters and state. This information is useful for debugging
|
||||
RCU itself, and can sometimes also help to debug abuses of RCU.
|
||||
The following sections describe the debugfs files and formats.
|
||||
|
||||
|
||||
Hierarchical RCU debugfs Files and Formats
|
||||
|
|
@ -210,9 +35,10 @@ rcu_bh:
|
|||
6 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=859/1 dn=0 df=15 of=0 ri=0 ql=0 b=10
|
||||
7 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=3761/1 dn=0 df=15 of=0 ri=0 ql=0 b=10
|
||||
|
||||
The first section lists the rcu_data structures for rcu, the second for
|
||||
rcu_bh. Each section has one line per CPU, or eight for this 8-CPU system.
|
||||
The fields are as follows:
|
||||
The first section lists the rcu_data structures for rcu_sched, the second
|
||||
for rcu_bh. Note that CONFIG_TREE_PREEMPT_RCU kernels will have an
|
||||
additional section for rcu_preempt. Each section has one line per CPU,
|
||||
or eight for this 8-CPU system. The fields are as follows:
|
||||
|
||||
o The number at the beginning of each line is the CPU number.
|
||||
CPUs numbers followed by an exclamation mark are offline,
|
||||
|
|
@ -223,9 +49,9 @@ o The number at the beginning of each line is the CPU number.
|
|||
|
||||
o "c" is the count of grace periods that this CPU believes have
|
||||
completed. CPUs in dynticks idle mode may lag quite a ways
|
||||
behind, for example, CPU 4 under "rcu" above, which has slept
|
||||
through the past 25 RCU grace periods. It is not unusual to
|
||||
see CPUs lagging by thousands of grace periods.
|
||||
behind, for example, CPU 4 under "rcu_sched" above, which has
|
||||
slept through the past 25 RCU grace periods. It is not unusual
|
||||
to see CPUs lagging by thousands of grace periods.
|
||||
|
||||
o "g" is the count of grace periods that this CPU believes have
|
||||
started. Again, CPUs in dynticks idle mode may lag behind.
|
||||
|
|
@ -308,8 +134,10 @@ The output of "cat rcu/rcugp" looks as follows:
|
|||
rcu_sched: completed=33062 gpnum=33063
|
||||
rcu_bh: completed=464 gpnum=464
|
||||
|
||||
Again, this output is for both "rcu" and "rcu_bh". The fields are
|
||||
taken from the rcu_state structure, and are as follows:
|
||||
Again, this output is for both "rcu_sched" and "rcu_bh". Note that
|
||||
kernels built with CONFIG_TREE_PREEMPT_RCU will have an additional
|
||||
"rcu_preempt" line. The fields are taken from the rcu_state structure,
|
||||
and are as follows:
|
||||
|
||||
o "completed" is the number of grace periods that have completed.
|
||||
It is comparable to the "c" field from rcu/rcudata in that a
|
||||
|
|
@ -324,23 +152,24 @@ o "gpnum" is the number of grace periods that have started. It is
|
|||
If these two fields are equal (as they are for "rcu_bh" above),
|
||||
then there is no grace period in progress, in other words, RCU
|
||||
is idle. On the other hand, if the two fields differ (as they
|
||||
do for "rcu" above), then an RCU grace period is in progress.
|
||||
do for "rcu_sched" above), then an RCU grace period is in progress.
|
||||
|
||||
|
||||
The output of "cat rcu/rcuhier" looks as follows, with very long lines:
|
||||
|
||||
c=6902 g=6903 s=2 jfq=3 j=72c7 nfqs=13142/nfqsng=0(13142) fqlh=6
|
||||
1/1 0:127 ^0
|
||||
3/3 0:35 ^0 0/0 36:71 ^1 0/0 72:107 ^2 0/0 108:127 ^3
|
||||
3/3f 0:5 ^0 2/3 6:11 ^1 0/0 12:17 ^2 0/0 18:23 ^3 0/0 24:29 ^4 0/0 30:35 ^5 0/0 36:41 ^0 0/0 42:47 ^1 0/0 48:53 ^2 0/0 54:59 ^3 0/0 60:65 ^4 0/0 66:71 ^5 0/0 72:77 ^0 0/0 78:83 ^1 0/0 84:89 ^2 0/0 90:95 ^3 0/0 96:101 ^4 0/0 102:107 ^5 0/0 108:113 ^0 0/0 114:119 ^1 0/0 120:125 ^2 0/0 126:127 ^3
|
||||
c=6902 g=6903 s=2 jfq=3 j=72c7 nfqs=13142/nfqsng=0(13142) fqlh=6 oqlen=0
|
||||
1/1 .>. 0:127 ^0
|
||||
3/3 .>. 0:35 ^0 0/0 .>. 36:71 ^1 0/0 .>. 72:107 ^2 0/0 .>. 108:127 ^3
|
||||
3/3f .>. 0:5 ^0 2/3 .>. 6:11 ^1 0/0 .>. 12:17 ^2 0/0 .>. 18:23 ^3 0/0 .>. 24:29 ^4 0/0 .>. 30:35 ^5 0/0 .>. 36:41 ^0 0/0 .>. 42:47 ^1 0/0 .>. 48:53 ^2 0/0 .>. 54:59 ^3 0/0 .>. 60:65 ^4 0/0 .>. 66:71 ^5 0/0 .>. 72:77 ^0 0/0 .>. 78:83 ^1 0/0 .>. 84:89 ^2 0/0 .>. 90:95 ^3 0/0 .>. 96:101 ^4 0/0 .>. 102:107 ^5 0/0 .>. 108:113 ^0 0/0 .>. 114:119 ^1 0/0 .>. 120:125 ^2 0/0 .>. 126:127 ^3
|
||||
rcu_bh:
|
||||
c=-226 g=-226 s=1 jfq=-5701 j=72c7 nfqs=88/nfqsng=0(88) fqlh=0
|
||||
0/1 0:127 ^0
|
||||
0/3 0:35 ^0 0/0 36:71 ^1 0/0 72:107 ^2 0/0 108:127 ^3
|
||||
0/3f 0:5 ^0 0/3 6:11 ^1 0/0 12:17 ^2 0/0 18:23 ^3 0/0 24:29 ^4 0/0 30:35 ^5 0/0 36:41 ^0 0/0 42:47 ^1 0/0 48:53 ^2 0/0 54:59 ^3 0/0 60:65 ^4 0/0 66:71 ^5 0/0 72:77 ^0 0/0 78:83 ^1 0/0 84:89 ^2 0/0 90:95 ^3 0/0 96:101 ^4 0/0 102:107 ^5 0/0 108:113 ^0 0/0 114:119 ^1 0/0 120:125 ^2 0/0 126:127 ^3
|
||||
c=-226 g=-226 s=1 jfq=-5701 j=72c7 nfqs=88/nfqsng=0(88) fqlh=0 oqlen=0
|
||||
0/1 .>. 0:127 ^0
|
||||
0/3 .>. 0:35 ^0 0/0 .>. 36:71 ^1 0/0 .>. 72:107 ^2 0/0 .>. 108:127 ^3
|
||||
0/3f .>. 0:5 ^0 0/3 .>. 6:11 ^1 0/0 .>. 12:17 ^2 0/0 .>. 18:23 ^3 0/0 .>. 24:29 ^4 0/0 .>. 30:35 ^5 0/0 .>. 36:41 ^0 0/0 .>. 42:47 ^1 0/0 .>. 48:53 ^2 0/0 .>. 54:59 ^3 0/0 .>. 60:65 ^4 0/0 .>. 66:71 ^5 0/0 .>. 72:77 ^0 0/0 .>. 78:83 ^1 0/0 .>. 84:89 ^2 0/0 .>. 90:95 ^3 0/0 .>. 96:101 ^4 0/0 .>. 102:107 ^5 0/0 .>. 108:113 ^0 0/0 .>. 114:119 ^1 0/0 .>. 120:125 ^2 0/0 .>. 126:127 ^3
|
||||
|
||||
This is once again split into "rcu" and "rcu_bh" portions. The fields are
|
||||
as follows:
|
||||
This is once again split into "rcu_sched" and "rcu_bh" portions,
|
||||
and CONFIG_TREE_PREEMPT_RCU kernels will again have an additional
|
||||
"rcu_preempt" section. The fields are as follows:
|
||||
|
||||
o "c" is exactly the same as "completed" under rcu/rcugp.
|
||||
|
||||
|
|
@ -372,6 +201,11 @@ o "fqlh" is the number of calls to force_quiescent_state() that
|
|||
exited immediately (without even being counted in nfqs above)
|
||||
due to contention on ->fqslock.
|
||||
|
||||
o "oqlen" is the number of callbacks on the "orphan" callback
|
||||
list. RCU callbacks are placed on this list by CPUs going
|
||||
offline, and are "adopted" either by the CPU helping the outgoing
|
||||
CPU or by the next rcu_barrier*() call, whichever comes first.
|
||||
|
||||
o Each element of the form "1/1 0:127 ^0" represents one struct
|
||||
rcu_node. Each line represents one level of the hierarchy, from
|
||||
root to leaves. It is best to think of the rcu_data structures
|
||||
|
|
@ -379,7 +213,7 @@ o Each element of the form "1/1 0:127 ^0" represents one struct
|
|||
might be either one, two, or three levels of rcu_node structures,
|
||||
depending on the relationship between CONFIG_RCU_FANOUT and
|
||||
CONFIG_NR_CPUS.
|
||||
|
||||
|
||||
o The numbers separated by the "/" are the qsmask followed
|
||||
by the qsmaskinit. The qsmask will have one bit
|
||||
set for each entity in the next lower level that
|
||||
|
|
@ -389,10 +223,19 @@ o Each element of the form "1/1 0:127 ^0" represents one struct
|
|||
The value of qsmaskinit is assigned to that of qsmask
|
||||
at the beginning of each grace period.
|
||||
|
||||
For example, for "rcu", the qsmask of the first entry
|
||||
of the lowest level is 0x14, meaning that we are still
|
||||
waiting for CPUs 2 and 4 to check in for the current
|
||||
grace period.
|
||||
For example, for "rcu_sched", the qsmask of the first
|
||||
entry of the lowest level is 0x14, meaning that we
|
||||
are still waiting for CPUs 2 and 4 to check in for the
|
||||
current grace period.
|
||||
|
||||
o The characters separated by the ">" indicate the state
|
||||
of the blocked-tasks lists. A "T" preceding the ">"
|
||||
indicates that at least one task blocked in an RCU
|
||||
read-side critical section blocks the current grace
|
||||
period, while a "." preceding the ">" indicates otherwise.
|
||||
The character following the ">" indicates similarly for
|
||||
the next grace period. A "T" should appear in this
|
||||
field only for rcu-preempt.
|
||||
|
||||
o The numbers separated by the ":" are the range of CPUs
|
||||
served by this struct rcu_node. This can be helpful
|
||||
|
|
@ -431,8 +274,9 @@ rcu_bh:
|
|||
6 np=120834 qsp=9902 cbr=0 cng=0 gpc=6 gps=3 nf=2 nn=110921
|
||||
7 np=144888 qsp=26336 cbr=0 cng=0 gpc=8 gps=2 nf=0 nn=118542
|
||||
|
||||
As always, this is once again split into "rcu" and "rcu_bh" portions.
|
||||
The fields are as follows:
|
||||
As always, this is once again split into "rcu_sched" and "rcu_bh"
|
||||
portions, with CONFIG_TREE_PREEMPT_RCU kernels having an additional
|
||||
"rcu_preempt" section. The fields are as follows:
|
||||
|
||||
o "np" is the number of times that __rcu_pending() has been invoked
|
||||
for the corresponding flavor of RCU.
|
||||
|
|
|
|||
|
|
@ -830,7 +830,7 @@ sched: Critical sections Grace period Barrier
|
|||
SRCU: Critical sections Grace period Barrier
|
||||
|
||||
srcu_read_lock synchronize_srcu N/A
|
||||
srcu_read_unlock
|
||||
srcu_read_unlock synchronize_srcu_expedited
|
||||
|
||||
SRCU: Initialization/cleanup
|
||||
init_srcu_struct
|
||||
|
|
|
|||
|
|
@ -55,4 +55,4 @@ Maintainers
|
|||
This board is maintained by Simtec Electronics.
|
||||
|
||||
|
||||
(c) 2004 Ben Dooks, Simtec Electronics
|
||||
Copyright 2004 Ben Dooks, Simtec Electronics
|
||||
|
|
|
|||
|
|
@ -134,4 +134,4 @@ Authour
|
|||
|
||||
|
||||
Ben Dooks, 03 October 2004
|
||||
(c) 2004 Ben Dooks, Simtec Electronics
|
||||
Copyright 2004 Ben Dooks, Simtec Electronics
|
||||
|
|
|
|||
|
|
@ -299,4 +299,4 @@ Port Contributors
|
|||
Document Author
|
||||
---------------
|
||||
|
||||
Ben Dooks, (c) 2004-2005,2006 Simtec Electronics
|
||||
Ben Dooks, Copyright 2004-2006 Simtec Electronics
|
||||
|
|
|
|||
|
|
@ -117,4 +117,4 @@ ATA
|
|||
Document Author
|
||||
---------------
|
||||
|
||||
Ben Dooks, (c) 2006 Simtec Electronics
|
||||
Ben Dooks, Copyright 2006 Simtec Electronics
|
||||
|
|
|
|||
|
|
@ -18,4 +18,4 @@ Camera Interface
|
|||
Document Author
|
||||
---------------
|
||||
|
||||
Ben Dooks, (c) 2006 Simtec Electronics
|
||||
Ben Dooks, Copyright 2006 Simtec Electronics
|
||||
|
|
|
|||
|
|
@ -133,5 +133,5 @@ Configuration
|
|||
Document Author
|
||||
---------------
|
||||
|
||||
Ben Dooks, (c) 2004 Simtec Electronics
|
||||
Ben Dooks, Copyright 2004 Simtec Electronics
|
||||
|
||||
|
|
|
|||
|
|
@ -90,4 +90,4 @@ Platform Data
|
|||
Document Author
|
||||
---------------
|
||||
|
||||
Ben Dooks, (c) 2005 Simtec Electronics
|
||||
Ben Dooks, Copyright 2005 Simtec Electronics
|
||||
|
|
|
|||
|
|
@ -0,0 +1,588 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||
<svg
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
version="1.0"
|
||||
width="210mm"
|
||||
height="297mm"
|
||||
viewBox="0 0 21000 29700"
|
||||
id="svg2"
|
||||
style="fill-rule:evenodd">
|
||||
<defs
|
||||
id="defs4" />
|
||||
<g
|
||||
id="Default"
|
||||
style="visibility:visible">
|
||||
<desc
|
||||
id="desc180">Master slide</desc>
|
||||
</g>
|
||||
<path
|
||||
d="M 11999,8601 L 11899,8301 L 12099,8301 L 11999,8601 z"
|
||||
id="path193"
|
||||
style="fill:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 11999,7801 L 11999,8361"
|
||||
id="path197"
|
||||
style="fill:none;stroke:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 7999,10401 L 7899,10101 L 8099,10101 L 7999,10401 z"
|
||||
id="path209"
|
||||
style="fill:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 7999,9601 L 7999,10161"
|
||||
id="path213"
|
||||
style="fill:none;stroke:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 11999,7801 L 11685,7840 L 11724,7644 L 11999,7801 z"
|
||||
id="path225"
|
||||
style="fill:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 7999,7001 L 11764,7754"
|
||||
id="path229"
|
||||
style="fill:none;stroke:#008000;visibility:visible" />
|
||||
<g
|
||||
transform="matrix(0.9895258,-0.1443562,0.1443562,0.9895258,-1244.4792,1416.5139)"
|
||||
id="g245"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<text
|
||||
id="text247">
|
||||
<tspan
|
||||
x="9139 9368 9579 9808 9986 10075 10252 10481 10659 10837 10909"
|
||||
y="9284"
|
||||
id="tspan249">RSDataReply</tspan>
|
||||
</text>
|
||||
</g>
|
||||
<path
|
||||
d="M 7999,9601 L 8281,9458 L 8311,9655 L 7999,9601 z"
|
||||
id="path259"
|
||||
style="fill:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 11999,9001 L 8236,9565"
|
||||
id="path263"
|
||||
style="fill:none;stroke:#008000;visibility:visible" />
|
||||
<g
|
||||
transform="matrix(0.9788674,0.2044961,-0.2044961,0.9788674,1620.9382,-1639.4947)"
|
||||
id="g279"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<text
|
||||
id="text281">
|
||||
<tspan
|
||||
x="8743 8972 9132 9310 9573 9801 10013 10242 10419 10597 10775 10953 11114"
|
||||
y="7023"
|
||||
id="tspan283">CsumRSRequest</tspan>
|
||||
</text>
|
||||
</g>
|
||||
<text
|
||||
id="text297"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="4034 4263 4440 4703 4881 5042 5219 5397 5503 5681 5842 6003 6180 6341 6519 6625 6803 6980 7158 7336 7497 7586 7692"
|
||||
y="5707"
|
||||
id="tspan299">w_make_resync_request()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text313"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="12199 12305 12483 12644 12821 12893 13054 13232 13410 13638 13816 13905 14083 14311 14489 14667 14845 15023 15184 15272 15378"
|
||||
y="7806"
|
||||
id="tspan315">receive_DataRequest()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text329"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="12199 12377 12483 12660 12838 13016 13194 13372 13549 13621 13799 13977 14083 14261 14438 14616 14794 14955 15133 15294 15399"
|
||||
y="8606"
|
||||
id="tspan331">drbd_endio_read_sec()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text345"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="12191 12420 12597 12775 12953 13131 13309 13486 13664 13825 13986 14164 14426 14604 14710 14871 15049 15154 15332 15510 15616"
|
||||
y="9007"
|
||||
id="tspan347">w_e_end_csum_rs_req()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text361"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="4444 4550 4728 4889 5066 5138 5299 5477 5655 5883 6095 6324 6501 6590 6768 6997 7175 7352 7424 7585 7691"
|
||||
y="9507"
|
||||
id="tspan363">receive_RSDataReply()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text377"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="4457 4635 4741 4918 5096 5274 5452 5630 5807 5879 6057 6235 6464 6569 6641 6730 6908 7086 7247 7425 7585 7691"
|
||||
y="10407"
|
||||
id="tspan379">drbd_endio_write_sec()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text393"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="4647 4825 5003 5180 5358 5536 5714 5820 5997 6158 6319 6497 6658 6836 7013 7085 7263 7424 7585 7691"
|
||||
y="10907"
|
||||
id="tspan395">e_end_resync_block()</tspan>
|
||||
</text>
|
||||
<path
|
||||
d="M 11999,11601 L 11685,11640 L 11724,11444 L 11999,11601 z"
|
||||
id="path405"
|
||||
style="fill:#000080;visibility:visible" />
|
||||
<path
|
||||
d="M 7999,10801 L 11764,11554"
|
||||
id="path409"
|
||||
style="fill:none;stroke:#000080;visibility:visible" />
|
||||
<g
|
||||
transform="matrix(0.9788674,0.2044961,-0.2044961,0.9788674,2434.7562,-1674.649)"
|
||||
id="g425"
|
||||
style="font-size:318px;font-weight:400;fill:#000080;visibility:visible;font-family:Helvetica embedded">
|
||||
<text
|
||||
id="text427">
|
||||
<tspan
|
||||
x="9320 9621 9726 9798 9887 10065 10277 10438"
|
||||
y="10943"
|
||||
id="tspan429">WriteAck</tspan>
|
||||
</text>
|
||||
</g>
|
||||
<text
|
||||
id="text443"
|
||||
style="font-size:318px;font-weight:400;fill:#000080;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="12199 12377 12555 12644 12821 13033 13105 13283 13444 13604 13816 13977 14138 14244"
|
||||
y="11559"
|
||||
id="tspan445">got_BlockAck()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text459"
|
||||
style="font-size:423px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="7999 8304 8541 8778 8990 9201 9413 9650 10001 10120 10357 10594 10806 11043 11280 11398 11703 11940 12152 12364 12601 12812 12931 13049 13261 13498 13710 13947 14065 14302 14540 14658 14777 14870 15107 15225 15437 15649 15886"
|
||||
y="4877"
|
||||
id="tspan461">Checksum based Resync, case not in sync</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text475"
|
||||
style="font-size:423px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="6961 7266 7571 7854 8159 8299 8536 8654 8891 9010 9247 9484 9603 9840 9958 10077 10170 10407"
|
||||
y="2806"
|
||||
id="tspan477">DRBD-8.3 data flow</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text491"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="5190 5419 5596 5774 5952 6113 6291 6468 6646 6824 6985 7146 7324 7586 7692"
|
||||
y="7005"
|
||||
id="tspan493">w_e_send_csum()</tspan>
|
||||
</text>
|
||||
<path
|
||||
d="M 11999,17601 L 11899,17301 L 12099,17301 L 11999,17601 z"
|
||||
id="path503"
|
||||
style="fill:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 11999,16801 L 11999,17361"
|
||||
id="path507"
|
||||
style="fill:none;stroke:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 11999,16801 L 11685,16840 L 11724,16644 L 11999,16801 z"
|
||||
id="path519"
|
||||
style="fill:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 7999,16001 L 11764,16754"
|
||||
id="path523"
|
||||
style="fill:none;stroke:#008000;visibility:visible" />
|
||||
<g
|
||||
transform="matrix(0.9895258,-0.1443562,0.1443562,0.9895258,-2539.5806,1529.3491)"
|
||||
id="g539"
|
||||
style="font-size:318px;font-weight:400;fill:#000080;visibility:visible;font-family:Helvetica embedded">
|
||||
<text
|
||||
id="text541">
|
||||
<tspan
|
||||
x="9269 9498 9709 9798 9959 10048 10226 10437 10598 10776"
|
||||
y="18265"
|
||||
id="tspan543">RSIsInSync</tspan>
|
||||
</text>
|
||||
</g>
|
||||
<path
|
||||
d="M 7999,18601 L 8281,18458 L 8311,18655 L 7999,18601 z"
|
||||
id="path553"
|
||||
style="fill:#000080;visibility:visible" />
|
||||
<path
|
||||
d="M 11999,18001 L 8236,18565"
|
||||
id="path557"
|
||||
style="fill:none;stroke:#000080;visibility:visible" />
|
||||
<g
|
||||
transform="matrix(0.9788674,0.2044961,-0.2044961,0.9788674,3461.4027,-1449.3012)"
|
||||
id="g573"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<text
|
||||
id="text575">
|
||||
<tspan
|
||||
x="8743 8972 9132 9310 9573 9801 10013 10242 10419 10597 10775 10953 11114"
|
||||
y="16023"
|
||||
id="tspan577">CsumRSRequest</tspan>
|
||||
</text>
|
||||
</g>
|
||||
<text
|
||||
id="text591"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="12199 12305 12483 12644 12821 12893 13054 13232 13410 13638 13816 13905 14083 14311 14489 14667 14845 15023 15184 15272 15378"
|
||||
y="16806"
|
||||
id="tspan593">receive_DataRequest()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text607"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="12199 12377 12483 12660 12838 13016 13194 13372 13549 13621 13799 13977 14083 14261 14438 14616 14794 14955 15133 15294 15399"
|
||||
y="17606"
|
||||
id="tspan609">drbd_endio_read_sec()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text623"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="12191 12420 12597 12775 12953 13131 13309 13486 13664 13825 13986 14164 14426 14604 14710 14871 15049 15154 15332 15510 15616"
|
||||
y="18007"
|
||||
id="tspan625">w_e_end_csum_rs_req()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text639"
|
||||
style="font-size:318px;font-weight:400;fill:#000080;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="5735 5913 6091 6180 6357 6446 6607 6696 6874 7085 7246 7424 7585 7691"
|
||||
y="18507"
|
||||
id="tspan641">got_IsInSync()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text655"
|
||||
style="font-size:423px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="7999 8304 8541 8778 8990 9201 9413 9650 10001 10120 10357 10594 10806 11043 11280 11398 11703 11940 12152 12364 12601 12812 12931 13049 13261 13498 13710 13947 14065 14159 14396 14514 14726 14937 15175"
|
||||
y="13877"
|
||||
id="tspan657">Checksum based Resync, case in sync</tspan>
|
||||
</text>
|
||||
<path
|
||||
d="M 12000,24601 L 11900,24301 L 12100,24301 L 12000,24601 z"
|
||||
id="path667"
|
||||
style="fill:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 12000,23801 L 12000,24361"
|
||||
id="path671"
|
||||
style="fill:none;stroke:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 8000,26401 L 7900,26101 L 8100,26101 L 8000,26401 z"
|
||||
id="path683"
|
||||
style="fill:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 8000,25601 L 8000,26161"
|
||||
id="path687"
|
||||
style="fill:none;stroke:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 12000,23801 L 11686,23840 L 11725,23644 L 12000,23801 z"
|
||||
id="path699"
|
||||
style="fill:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 8000,23001 L 11765,23754"
|
||||
id="path703"
|
||||
style="fill:none;stroke:#008000;visibility:visible" />
|
||||
<g
|
||||
transform="matrix(0.9895258,-0.1443562,0.1443562,0.9895258,-3543.8452,1630.5143)"
|
||||
id="g719"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<text
|
||||
id="text721">
|
||||
<tspan
|
||||
x="9464 9710 9921 10150 10328 10505 10577"
|
||||
y="25236"
|
||||
id="tspan723">OVReply</tspan>
|
||||
</text>
|
||||
</g>
|
||||
<path
|
||||
d="M 8000,25601 L 8282,25458 L 8312,25655 L 8000,25601 z"
|
||||
id="path733"
|
||||
style="fill:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 12000,25001 L 8237,25565"
|
||||
id="path737"
|
||||
style="fill:none;stroke:#008000;visibility:visible" />
|
||||
<g
|
||||
transform="matrix(0.9788674,0.2044961,-0.2044961,0.9788674,4918.2801,-1381.2128)"
|
||||
id="g753"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<text
|
||||
id="text755">
|
||||
<tspan
|
||||
x="9142 9388 9599 9828 10006 10183 10361 10539 10700"
|
||||
y="23106"
|
||||
id="tspan757">OVRequest</tspan>
|
||||
</text>
|
||||
</g>
|
||||
<text
|
||||
id="text771"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="12200 12306 12484 12645 12822 12894 13055 13233 13411 13656 13868 14097 14274 14452 14630 14808 14969 15058 15163"
|
||||
y="23806"
|
||||
id="tspan773">receive_OVRequest()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text787"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="12200 12378 12484 12661 12839 13017 13195 13373 13550 13622 13800 13978 14084 14262 14439 14617 14795 14956 15134 15295 15400"
|
||||
y="24606"
|
||||
id="tspan789">drbd_endio_read_sec()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text803"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="12192 12421 12598 12776 12954 13132 13310 13487 13665 13843 14004 14182 14288 14465 14643 14749"
|
||||
y="25007"
|
||||
id="tspan805">w_e_end_ov_req()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text819"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="5101 5207 5385 5546 5723 5795 5956 6134 6312 6557 6769 6998 7175 7353 7425 7586 7692"
|
||||
y="25507"
|
||||
id="tspan821">receive_OVReply()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text835"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="4492 4670 4776 4953 5131 5309 5487 5665 5842 5914 6092 6270 6376 6554 6731 6909 7087 7248 7426 7587 7692"
|
||||
y="26407"
|
||||
id="tspan837">drbd_endio_read_sec()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text851"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="4902 5131 5308 5486 5664 5842 6020 6197 6375 6553 6714 6892 6998 7175 7353 7425 7586 7692"
|
||||
y="26907"
|
||||
id="tspan853">w_e_end_ov_reply()</tspan>
|
||||
</text>
|
||||
<path
|
||||
d="M 12000,27601 L 11686,27640 L 11725,27444 L 12000,27601 z"
|
||||
id="path863"
|
||||
style="fill:#000080;visibility:visible" />
|
||||
<path
|
||||
d="M 8000,26801 L 11765,27554"
|
||||
id="path867"
|
||||
style="fill:none;stroke:#000080;visibility:visible" />
|
||||
<g
|
||||
transform="matrix(0.9788674,0.2044961,-0.2044961,0.9788674,5704.1907,-1328.312)"
|
||||
id="g883"
|
||||
style="font-size:318px;font-weight:400;fill:#000080;visibility:visible;font-family:Helvetica embedded">
|
||||
<text
|
||||
id="text885">
|
||||
<tspan
|
||||
x="9279 9525 9736 9965 10143 10303 10481 10553"
|
||||
y="26935"
|
||||
id="tspan887">OVResult</tspan>
|
||||
</text>
|
||||
</g>
|
||||
<text
|
||||
id="text901"
|
||||
style="font-size:318px;font-weight:400;fill:#000080;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="12200 12378 12556 12645 12822 13068 13280 13508 13686 13847 14025 14097 14185 14291"
|
||||
y="27559"
|
||||
id="tspan903">got_OVResult()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text917"
|
||||
style="font-size:423px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="8000 8330 8567 8660 8754 8991 9228 9346 9558 9795 9935 10028 10146"
|
||||
y="21877"
|
||||
id="tspan919">Online verify</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text933"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="4641 4870 5047 5310 5488 5649 5826 6004 6182 6343 6521 6626 6804 6982 7160 7338 7499 7587 7693"
|
||||
y="23005"
|
||||
id="tspan935">w_make_ov_request()</tspan>
|
||||
</text>
|
||||
<path
|
||||
d="M 8000,6500 L 7900,6200 L 8100,6200 L 8000,6500 z"
|
||||
id="path945"
|
||||
style="fill:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 8000,5700 L 8000,6260"
|
||||
id="path949"
|
||||
style="fill:none;stroke:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 3900,5500 L 3700,5500 L 3700,11000 L 3900,11000"
|
||||
id="path961"
|
||||
style="fill:none;stroke:#000000;visibility:visible" />
|
||||
<path
|
||||
d="M 3900,14500 L 3700,14500 L 3700,18600 L 3900,18600"
|
||||
id="path973"
|
||||
style="fill:none;stroke:#000000;visibility:visible" />
|
||||
<path
|
||||
d="M 3900,22800 L 3700,22800 L 3700,26900 L 3900,26900"
|
||||
id="path985"
|
||||
style="fill:none;stroke:#000000;visibility:visible" />
|
||||
<text
|
||||
id="text1001"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="4492 4670 4776 4953 5131 5309 5487 5665 5842 5914 6092 6270 6376 6554 6731 6909 7087 7248 7426 7587 7692"
|
||||
y="6506"
|
||||
id="tspan1003">drbd_endio_read_sec()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text1017"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="4034 4263 4440 4703 4881 5042 5219 5397 5503 5681 5842 6003 6180 6341 6519 6625 6803 6980 7158 7336 7497 7586 7692"
|
||||
y="14708"
|
||||
id="tspan1019">w_make_resync_request()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text1033"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="5190 5419 5596 5774 5952 6113 6291 6468 6646 6824 6985 7146 7324 7586 7692"
|
||||
y="16006"
|
||||
id="tspan1035">w_e_send_csum()</tspan>
|
||||
</text>
|
||||
<path
|
||||
d="M 8000,15501 L 7900,15201 L 8100,15201 L 8000,15501 z"
|
||||
id="path1045"
|
||||
style="fill:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 8000,14701 L 8000,15261"
|
||||
id="path1049"
|
||||
style="fill:none;stroke:#008000;visibility:visible" />
|
||||
<text
|
||||
id="text1065"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="4492 4670 4776 4953 5131 5309 5487 5665 5842 5914 6092 6270 6376 6554 6731 6909 7087 7248 7426 7587 7692"
|
||||
y="15507"
|
||||
id="tspan1067">drbd_endio_read_sec()</tspan>
|
||||
</text>
|
||||
<path
|
||||
d="M 16100,9000 L 16300,9000 L 16300,7500 L 16100,7500"
|
||||
id="path1077"
|
||||
style="fill:none;stroke:#000000;visibility:visible" />
|
||||
<path
|
||||
d="M 16100,18000 L 16300,18000 L 16300,16500 L 16100,16500"
|
||||
id="path1089"
|
||||
style="fill:none;stroke:#000000;visibility:visible" />
|
||||
<path
|
||||
d="M 16100,25000 L 16300,25000 L 16300,23500 L 16100,23500"
|
||||
id="path1101"
|
||||
style="fill:none;stroke:#000000;visibility:visible" />
|
||||
<text
|
||||
id="text1117"
|
||||
style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="2026 2132 2293 2471 2648 2826 3004 3076 3254 3431 3503 3681 3787"
|
||||
y="5402"
|
||||
id="tspan1119">rs_begin_io()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text1133"
|
||||
style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="2027 2133 2294 2472 2649 2827 3005 3077 3255 3432 3504 3682 3788"
|
||||
y="14402"
|
||||
id="tspan1135">rs_begin_io()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text1149"
|
||||
style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="2026 2132 2293 2471 2648 2826 3004 3076 3254 3431 3503 3681 3787"
|
||||
y="22602"
|
||||
id="tspan1151">rs_begin_io()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text1165"
|
||||
style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="1426 1532 1693 1871 2031 2209 2472 2649 2721 2899 2988 3166 3344 3416 3593 3699"
|
||||
y="11302"
|
||||
id="tspan1167">rs_complete_io()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text1181"
|
||||
style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="1526 1632 1793 1971 2131 2309 2572 2749 2821 2999 3088 3266 3444 3516 3693 3799"
|
||||
y="18931"
|
||||
id="tspan1183">rs_complete_io()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text1197"
|
||||
style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="1526 1632 1793 1971 2131 2309 2572 2749 2821 2999 3088 3266 3444 3516 3693 3799"
|
||||
y="27231"
|
||||
id="tspan1199">rs_complete_io()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text1213"
|
||||
style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="16126 16232 16393 16571 16748 16926 17104 17176 17354 17531 17603 17781 17887"
|
||||
y="7402"
|
||||
id="tspan1215">rs_begin_io()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text1229"
|
||||
style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="16127 16233 16394 16572 16749 16927 17105 17177 17355 17532 17604 17782 17888"
|
||||
y="16331"
|
||||
id="tspan1231">rs_begin_io()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text1245"
|
||||
style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="16127 16233 16394 16572 16749 16927 17105 17177 17355 17532 17604 17782 17888"
|
||||
y="23302"
|
||||
id="tspan1247">rs_begin_io()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text1261"
|
||||
style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="16115 16221 16382 16560 16720 16898 17161 17338 17410 17588 17677 17855 18033 18105 18282 18388"
|
||||
y="9302"
|
||||
id="tspan1263">rs_complete_io()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text1277"
|
||||
style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="16115 16221 16382 16560 16720 16898 17161 17338 17410 17588 17677 17855 18033 18105 18282 18388"
|
||||
y="18331"
|
||||
id="tspan1279">rs_complete_io()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text1293"
|
||||
style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="16126 16232 16393 16571 16731 16909 17172 17349 17421 17599 17688 17866 18044 18116 18293 18399"
|
||||
y="25302"
|
||||
id="tspan1295">rs_complete_io()</tspan>
|
||||
</text>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 22 KiB |
|
|
@ -0,0 +1,459 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||
<svg
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
version="1.0"
|
||||
width="210mm"
|
||||
height="297mm"
|
||||
viewBox="0 0 21000 29700"
|
||||
id="svg2"
|
||||
style="fill-rule:evenodd">
|
||||
<defs
|
||||
id="defs4" />
|
||||
<g
|
||||
id="Default"
|
||||
style="visibility:visible">
|
||||
<desc
|
||||
id="desc176">Master slide</desc>
|
||||
</g>
|
||||
<path
|
||||
d="M 11999,19601 L 11899,19301 L 12099,19301 L 11999,19601 z"
|
||||
id="path189"
|
||||
style="fill:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 11999,18801 L 11999,19361"
|
||||
id="path193"
|
||||
style="fill:none;stroke:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 7999,21401 L 7899,21101 L 8099,21101 L 7999,21401 z"
|
||||
id="path205"
|
||||
style="fill:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 7999,20601 L 7999,21161"
|
||||
id="path209"
|
||||
style="fill:none;stroke:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 11999,18801 L 11685,18840 L 11724,18644 L 11999,18801 z"
|
||||
id="path221"
|
||||
style="fill:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 7999,18001 L 11764,18754"
|
||||
id="path225"
|
||||
style="fill:none;stroke:#008000;visibility:visible" />
|
||||
<text
|
||||
x="-3023.845"
|
||||
y="1106.8124"
|
||||
transform="matrix(0.9895258,-0.1443562,0.1443562,0.9895258,0,0)"
|
||||
id="text243"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="6115.1553 6344.1553 6555.1553 6784.1553 6962.1553 7051.1553 7228.1553 7457.1553 7635.1553 7813.1553 7885.1553"
|
||||
y="21390.812"
|
||||
id="tspan245">RSDataReply</tspan>
|
||||
</text>
|
||||
<path
|
||||
d="M 7999,20601 L 8281,20458 L 8311,20655 L 7999,20601 z"
|
||||
id="path255"
|
||||
style="fill:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 11999,20001 L 8236,20565"
|
||||
id="path259"
|
||||
style="fill:none;stroke:#008000;visibility:visible" />
|
||||
<text
|
||||
x="3502.5356"
|
||||
y="-2184.6621"
|
||||
transform="matrix(0.9788674,0.2044961,-0.2044961,0.9788674,0,0)"
|
||||
id="text277"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="12321.536 12550.536 12761.536 12990.536 13168.536 13257.536 13434.536 13663.536 13841.536 14019.536 14196.536 14374.536 14535.536"
|
||||
y="15854.338"
|
||||
id="tspan279">RSDataRequest</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text293"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="4034 4263 4440 4703 4881 5042 5219 5397 5503 5681 5842 6003 6180 6341 6519 6625 6803 6980 7158 7336 7497 7586 7692"
|
||||
y="17807"
|
||||
id="tspan295">w_make_resync_request()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text309"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="12199 12305 12483 12644 12821 12893 13054 13232 13410 13638 13816 13905 14083 14311 14489 14667 14845 15023 15184 15272 15378"
|
||||
y="18806"
|
||||
id="tspan311">receive_DataRequest()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text325"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="12199 12377 12483 12660 12838 13016 13194 13372 13549 13621 13799 13977 14083 14261 14438 14616 14794 14955 15133 15294 15399"
|
||||
y="19606"
|
||||
id="tspan327">drbd_endio_read_sec()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text341"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="12191 12420 12597 12775 12953 13131 13309 13486 13664 13770 13931 14109 14287 14375 14553 14731 14837 15015 15192 15298"
|
||||
y="20007"
|
||||
id="tspan343">w_e_end_rsdata_req()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text357"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="4444 4550 4728 4889 5066 5138 5299 5477 5655 5883 6095 6324 6501 6590 6768 6997 7175 7352 7424 7585 7691"
|
||||
y="20507"
|
||||
id="tspan359">receive_RSDataReply()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text373"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="4457 4635 4741 4918 5096 5274 5452 5630 5807 5879 6057 6235 6464 6569 6641 6730 6908 7086 7247 7425 7585 7691"
|
||||
y="21407"
|
||||
id="tspan375">drbd_endio_write_sec()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text389"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="4647 4825 5003 5180 5358 5536 5714 5820 5997 6158 6319 6497 6658 6836 7013 7085 7263 7424 7585 7691"
|
||||
y="21907"
|
||||
id="tspan391">e_end_resync_block()</tspan>
|
||||
</text>
|
||||
<path
|
||||
d="M 11999,22601 L 11685,22640 L 11724,22444 L 11999,22601 z"
|
||||
id="path401"
|
||||
style="fill:#000080;visibility:visible" />
|
||||
<path
|
||||
d="M 7999,21801 L 11764,22554"
|
||||
id="path405"
|
||||
style="fill:none;stroke:#000080;visibility:visible" />
|
||||
<text
|
||||
x="4290.3008"
|
||||
y="-2369.6162"
|
||||
transform="matrix(0.9788674,0.2044961,-0.2044961,0.9788674,0,0)"
|
||||
id="text423"
|
||||
style="font-size:318px;font-weight:400;fill:#000080;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="13610.301 13911.301 14016.301 14088.301 14177.301 14355.301 14567.301 14728.301"
|
||||
y="19573.385"
|
||||
id="tspan425">WriteAck</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text439"
|
||||
style="font-size:318px;font-weight:400;fill:#000080;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="12199 12377 12555 12644 12821 13033 13105 13283 13444 13604 13816 13977 14138 14244"
|
||||
y="22559"
|
||||
id="tspan441">got_BlockAck()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text455"
|
||||
style="font-size:423px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="7999 8304 8541 8753 8964 9201 9413 9531 9769 9862 10099 10310 10522 10734 10852 10971 11208 11348 11585 11822"
|
||||
y="16877"
|
||||
id="tspan457">Resync blocks, 4-32K</tspan>
|
||||
</text>
|
||||
<path
|
||||
d="M 12000,7601 L 11900,7301 L 12100,7301 L 12000,7601 z"
|
||||
id="path467"
|
||||
style="fill:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 12000,6801 L 12000,7361"
|
||||
id="path471"
|
||||
style="fill:none;stroke:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 12000,6801 L 11686,6840 L 11725,6644 L 12000,6801 z"
|
||||
id="path483"
|
||||
style="fill:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 8000,6001 L 11765,6754"
|
||||
id="path487"
|
||||
style="fill:none;stroke:#008000;visibility:visible" />
|
||||
<text
|
||||
x="-1288.1796"
|
||||
y="1279.7666"
|
||||
transform="matrix(0.9895258,-0.1443562,0.1443562,0.9895258,0,0)"
|
||||
id="text505"
|
||||
style="font-size:318px;font-weight:400;fill:#000080;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="8174.8208 8475.8203 8580.8203 8652.8203 8741.8203 8919.8203 9131.8203 9292.8203"
|
||||
y="9516.7666"
|
||||
id="tspan507">WriteAck</tspan>
|
||||
</text>
|
||||
<path
|
||||
d="M 8000,8601 L 8282,8458 L 8312,8655 L 8000,8601 z"
|
||||
id="path517"
|
||||
style="fill:#000080;visibility:visible" />
|
||||
<path
|
||||
d="M 12000,8001 L 8237,8565"
|
||||
id="path521"
|
||||
style="fill:none;stroke:#000080;visibility:visible" />
|
||||
<text
|
||||
x="1065.6655"
|
||||
y="-2097.7664"
|
||||
transform="matrix(0.9788674,0.2044961,-0.2044961,0.9788674,0,0)"
|
||||
id="text539"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="10682.666 10911.666 11088.666 11177.666"
|
||||
y="4107.2339"
|
||||
id="tspan541">Data</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text555"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="4746 4924 5030 5207 5385 5563 5826 6003 6164 6342 6520 6626 6803 6981 7159 7337 7498 7587 7692"
|
||||
y="5505"
|
||||
id="tspan557">drbd_make_request()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text571"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="12200 12306 12484 12645 12822 12894 13055 13233 13411 13639 13817 13906 14084 14190"
|
||||
y="6806"
|
||||
id="tspan573">receive_Data()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text587"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="12200 12378 12484 12661 12839 13017 13195 13373 13550 13622 13800 13978 14207 14312 14384 14473 14651 14829 14990 15168 15328 15434"
|
||||
y="7606"
|
||||
id="tspan589">drbd_endio_write_sec()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text603"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="12192 12370 12548 12725 12903 13081 13259 13437 13509 13686 13847 14008 14114"
|
||||
y="8007"
|
||||
id="tspan605">e_end_block()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text619"
|
||||
style="font-size:318px;font-weight:400;fill:#000080;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="5647 5825 6003 6092 6269 6481 6553 6731 6892 7052 7264 7425 7586 7692"
|
||||
y="8606"
|
||||
id="tspan621">got_BlockAck()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text635"
|
||||
style="font-size:423px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="8000 8305 8542 8779 9016 9109 9346 9486 9604 9956 10049 10189 10328 10565 10705 10942 11179 11298 11603 11742 11835 11954 12191 12310 12428 12665 12902 13139 13279 13516 13753"
|
||||
y="4877"
|
||||
id="tspan637">Regular mirrored write, 512-32K</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text651"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="5381 5610 5787 5948 6126 6304 6482 6659 6837 7015 7087 7265 7426 7587 7692"
|
||||
y="6003"
|
||||
id="tspan653">w_send_dblock()</tspan>
|
||||
</text>
|
||||
<path
|
||||
d="M 8000,6800 L 7900,6500 L 8100,6500 L 8000,6800 z"
|
||||
id="path663"
|
||||
style="fill:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 8000,6000 L 8000,6560"
|
||||
id="path667"
|
||||
style="fill:none;stroke:#008000;visibility:visible" />
|
||||
<text
|
||||
id="text683"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="4602 4780 4886 5063 5241 5419 5597 5775 5952 6024 6202 6380 6609 6714 6786 6875 7053 7231 7409 7515 7587 7692"
|
||||
y="6905"
|
||||
id="tspan685">drbd_endio_write_pri()</tspan>
|
||||
</text>
|
||||
<path
|
||||
d="M 12000,13602 L 11900,13302 L 12100,13302 L 12000,13602 z"
|
||||
id="path695"
|
||||
style="fill:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 12000,12802 L 12000,13362"
|
||||
id="path699"
|
||||
style="fill:none;stroke:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 12000,12802 L 11686,12841 L 11725,12645 L 12000,12802 z"
|
||||
id="path711"
|
||||
style="fill:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 8000,12002 L 11765,12755"
|
||||
id="path715"
|
||||
style="fill:none;stroke:#008000;visibility:visible" />
|
||||
<text
|
||||
x="-2155.5266"
|
||||
y="1201.5964"
|
||||
transform="matrix(0.9895258,-0.1443562,0.1443562,0.9895258,0,0)"
|
||||
id="text733"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="7202.4736 7431.4736 7608.4736 7697.4736 7875.4736 8104.4736 8282.4736 8459.4736 8531.4736"
|
||||
y="15454.597"
|
||||
id="tspan735">DataReply</tspan>
|
||||
</text>
|
||||
<path
|
||||
d="M 8000,14602 L 8282,14459 L 8312,14656 L 8000,14602 z"
|
||||
id="path745"
|
||||
style="fill:#008000;visibility:visible" />
|
||||
<path
|
||||
d="M 12000,14002 L 8237,14566"
|
||||
id="path749"
|
||||
style="fill:none;stroke:#008000;visibility:visible" />
|
||||
<text
|
||||
x="2280.3804"
|
||||
y="-2103.2141"
|
||||
transform="matrix(0.9788674,0.2044961,-0.2044961,0.9788674,0,0)"
|
||||
id="text767"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="11316.381 11545.381 11722.381 11811.381 11989.381 12218.381 12396.381 12573.381 12751.381 12929.381 13090.381"
|
||||
y="9981.7861"
|
||||
id="tspan769">DataRequest</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text783"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="4746 4924 5030 5207 5385 5563 5826 6003 6164 6342 6520 6626 6803 6981 7159 7337 7498 7587 7692"
|
||||
y="11506"
|
||||
id="tspan785">drbd_make_request()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text799"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="12200 12306 12484 12645 12822 12894 13055 13233 13411 13639 13817 13906 14084 14312 14490 14668 14846 15024 15185 15273 15379"
|
||||
y="12807"
|
||||
id="tspan801">receive_DataRequest()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text815"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="12200 12378 12484 12661 12839 13017 13195 13373 13550 13622 13800 13978 14084 14262 14439 14617 14795 14956 15134 15295 15400"
|
||||
y="13607"
|
||||
id="tspan817">drbd_endio_read_sec()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text831"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="12192 12421 12598 12776 12954 13132 13310 13487 13665 13843 14021 14110 14288 14465 14571 14749 14927 15033"
|
||||
y="14008"
|
||||
id="tspan833">w_e_end_data_req()</tspan>
|
||||
</text>
|
||||
<g
|
||||
id="g835"
|
||||
style="visibility:visible">
|
||||
<desc
|
||||
id="desc837">Drawing</desc>
|
||||
<text
|
||||
id="text847"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="4885 4991 5169 5330 5507 5579 5740 5918 6096 6324 6502 6591 6769 6997 7175 7353 7425 7586 7692"
|
||||
y="14607"
|
||||
id="tspan849">receive_DataReply()</tspan>
|
||||
</text>
|
||||
</g>
|
||||
<text
|
||||
id="text863"
|
||||
style="font-size:423px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="8000 8305 8398 8610 8821 8914 9151 9363 9575 9693 9833 10070 10307 10544 10663 10781 11018 11255 11493 11632 11869 12106"
|
||||
y="10878"
|
||||
id="tspan865">Diskless read, 512-32K</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text879"
|
||||
style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="5029 5258 5435 5596 5774 5952 6130 6307 6413 6591 6769 6947 7125 7230 7408 7586 7692"
|
||||
y="12004"
|
||||
id="tspan881">w_send_read_req()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text895"
|
||||
style="font-size:423px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="6961 7266 7571 7854 8159 8278 8515 8633 8870 9107 9226 9463 9581 9700 9793 10030"
|
||||
y="2806"
|
||||
id="tspan897">DRBD 8 data flow</tspan>
|
||||
</text>
|
||||
<path
|
||||
d="M 3900,5300 L 3700,5300 L 3700,7000 L 3900,7000"
|
||||
id="path907"
|
||||
style="fill:none;stroke:#000000;visibility:visible" />
|
||||
<path
|
||||
d="M 3900,17600 L 3700,17600 L 3700,22000 L 3900,22000"
|
||||
id="path919"
|
||||
style="fill:none;stroke:#000000;visibility:visible" />
|
||||
<path
|
||||
d="M 16100,20000 L 16300,20000 L 16300,18500 L 16100,18500"
|
||||
id="path931"
|
||||
style="fill:none;stroke:#000000;visibility:visible" />
|
||||
<text
|
||||
id="text947"
|
||||
style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="2126 2304 2376 2554 2731 2909 3087 3159 3337 3515 3587 3764 3870"
|
||||
y="5202"
|
||||
id="tspan949">al_begin_io()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text963"
|
||||
style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="1632 1810 1882 2060 2220 2398 2661 2839 2910 3088 3177 3355 3533 3605 3783 3888"
|
||||
y="7331"
|
||||
id="tspan965">al_complete_io()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text979"
|
||||
style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="2126 2232 2393 2571 2748 2926 3104 3176 3354 3531 3603 3781 3887"
|
||||
y="17431"
|
||||
id="tspan981">rs_begin_io()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text995"
|
||||
style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="1626 1732 1893 2071 2231 2409 2672 2849 2921 3099 3188 3366 3544 3616 3793 3899"
|
||||
y="22331"
|
||||
id="tspan997">rs_complete_io()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text1011"
|
||||
style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="16027 16133 16294 16472 16649 16827 17005 17077 17255 17432 17504 17682 17788"
|
||||
y="18402"
|
||||
id="tspan1013">rs_begin_io()</tspan>
|
||||
</text>
|
||||
<text
|
||||
id="text1027"
|
||||
style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded">
|
||||
<tspan
|
||||
x="16115 16221 16382 16560 16720 16898 17161 17338 17410 17588 17677 17855 18033 18105 18282 18388"
|
||||
y="20331"
|
||||
id="tspan1029">rs_complete_io()</tspan>
|
||||
</text>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 17 KiB |
|
|
@ -0,0 +1,16 @@
|
|||
Description
|
||||
|
||||
DRBD is a shared-nothing, synchronously replicated block device. It
|
||||
is designed to serve as a building block for high availability
|
||||
clusters and in this context, is a "drop-in" replacement for shared
|
||||
storage. Simplistically, you could see it as a network RAID 1.
|
||||
|
||||
Please visit http://www.drbd.org to find out more.
|
||||
|
||||
The here included files are intended to help understand the implementation
|
||||
|
||||
DRBD-8.3-data-packets.svg, DRBD-data-packets.svg
|
||||
relates some functions, and write packets.
|
||||
|
||||
conn-states-8.dot, disk-states-8.dot, node-states-8.dot
|
||||
The sub graphs of DRBD's state transitions
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
digraph conn_states {
|
||||
StandAllone -> WFConnection [ label = "ioctl_set_net()" ]
|
||||
WFConnection -> Unconnected [ label = "unable to bind()" ]
|
||||
WFConnection -> WFReportParams [ label = "in connect() after accept" ]
|
||||
WFReportParams -> StandAllone [ label = "checks in receive_param()" ]
|
||||
WFReportParams -> Connected [ label = "in receive_param()" ]
|
||||
WFReportParams -> WFBitMapS [ label = "sync_handshake()" ]
|
||||
WFReportParams -> WFBitMapT [ label = "sync_handshake()" ]
|
||||
WFBitMapS -> SyncSource [ label = "receive_bitmap()" ]
|
||||
WFBitMapT -> SyncTarget [ label = "receive_bitmap()" ]
|
||||
SyncSource -> Connected
|
||||
SyncTarget -> Connected
|
||||
SyncSource -> PausedSyncS
|
||||
SyncTarget -> PausedSyncT
|
||||
PausedSyncS -> SyncSource
|
||||
PausedSyncT -> SyncTarget
|
||||
Connected -> WFConnection [ label = "* on network error" ]
|
||||
}
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
digraph disk_states {
|
||||
Diskless -> Inconsistent [ label = "ioctl_set_disk()" ]
|
||||
Diskless -> Consistent [ label = "ioctl_set_disk()" ]
|
||||
Diskless -> Outdated [ label = "ioctl_set_disk()" ]
|
||||
Consistent -> Outdated [ label = "receive_param()" ]
|
||||
Consistent -> UpToDate [ label = "receive_param()" ]
|
||||
Consistent -> Inconsistent [ label = "start resync" ]
|
||||
Outdated -> Inconsistent [ label = "start resync" ]
|
||||
UpToDate -> Inconsistent [ label = "ioctl_replicate" ]
|
||||
Inconsistent -> UpToDate [ label = "resync completed" ]
|
||||
Consistent -> Failed [ label = "io completion error" ]
|
||||
Outdated -> Failed [ label = "io completion error" ]
|
||||
UpToDate -> Failed [ label = "io completion error" ]
|
||||
Inconsistent -> Failed [ label = "io completion error" ]
|
||||
Failed -> Diskless [ label = "sending notify to peer" ]
|
||||
}
|
||||
|
|
@ -0,0 +1,85 @@
|
|||
// vim: set sw=2 sts=2 :
|
||||
digraph {
|
||||
rankdir=BT
|
||||
bgcolor=white
|
||||
|
||||
node [shape=plaintext]
|
||||
node [fontcolor=black]
|
||||
|
||||
StandAlone [ style=filled,fillcolor=gray,label=StandAlone ]
|
||||
|
||||
node [fontcolor=lightgray]
|
||||
|
||||
Unconnected [ label=Unconnected ]
|
||||
|
||||
CommTrouble [ shape=record,
|
||||
label="{communication loss|{Timeout|BrokenPipe|NetworkFailure}}" ]
|
||||
|
||||
node [fontcolor=gray]
|
||||
|
||||
subgraph cluster_try_connect {
|
||||
label="try to connect, handshake"
|
||||
rank=max
|
||||
WFConnection [ label=WFConnection ]
|
||||
WFReportParams [ label=WFReportParams ]
|
||||
}
|
||||
|
||||
TearDown [ label=TearDown ]
|
||||
|
||||
Connected [ label=Connected,style=filled,fillcolor=green,fontcolor=black ]
|
||||
|
||||
node [fontcolor=lightblue]
|
||||
|
||||
StartingSyncS [ label=StartingSyncS ]
|
||||
StartingSyncT [ label=StartingSyncT ]
|
||||
|
||||
subgraph cluster_bitmap_exchange {
|
||||
node [fontcolor=red]
|
||||
fontcolor=red
|
||||
label="new application (WRITE?) requests blocked\lwhile bitmap is exchanged"
|
||||
|
||||
WFBitMapT [ label=WFBitMapT ]
|
||||
WFSyncUUID [ label=WFSyncUUID ]
|
||||
WFBitMapS [ label=WFBitMapS ]
|
||||
}
|
||||
|
||||
node [fontcolor=blue]
|
||||
|
||||
cluster_resync [ shape=record,label="{<any>resynchronisation process running\l'concurrent' application requests allowed|{{<T>PausedSyncT\nSyncTarget}|{<S>PausedSyncS\nSyncSource}}}" ]
|
||||
|
||||
node [shape=box,fontcolor=black]
|
||||
|
||||
// drbdadm [label="drbdadm connect"]
|
||||
// handshake [label="drbd_connect()\ndrbd_do_handshake\ndrbd_sync_handshake() etc."]
|
||||
// comm_error [label="communication trouble"]
|
||||
|
||||
//
|
||||
// edges
|
||||
// --------------------------------------
|
||||
|
||||
StandAlone -> Unconnected [ label="drbdadm connect" ]
|
||||
Unconnected -> StandAlone [ label="drbdadm disconnect\lor serious communication trouble" ]
|
||||
Unconnected -> WFConnection [ label="receiver thread is started" ]
|
||||
WFConnection -> WFReportParams [ headlabel="accept()\land/or \lconnect()\l" ]
|
||||
|
||||
WFReportParams -> StandAlone [ label="during handshake\lpeers do not agree\labout something essential" ]
|
||||
WFReportParams -> Connected [ label="data identical\lno sync needed",color=green,fontcolor=green ]
|
||||
|
||||
WFReportParams -> WFBitMapS
|
||||
WFReportParams -> WFBitMapT
|
||||
WFBitMapT -> WFSyncUUID [minlen=0.1,constraint=false]
|
||||
|
||||
WFBitMapS -> cluster_resync:S
|
||||
WFSyncUUID -> cluster_resync:T
|
||||
|
||||
edge [color=green]
|
||||
cluster_resync:any -> Connected [ label="resnyc done",fontcolor=green ]
|
||||
|
||||
edge [color=red]
|
||||
WFReportParams -> CommTrouble
|
||||
Connected -> CommTrouble
|
||||
cluster_resync:any -> CommTrouble
|
||||
edge [color=black]
|
||||
CommTrouble -> Unconnected [label="receiver thread is stopped" ]
|
||||
|
||||
}
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
digraph node_states {
|
||||
Secondary -> Primary [ label = "ioctl_set_state()" ]
|
||||
Primary -> Secondary [ label = "ioctl_set_state()" ]
|
||||
}
|
||||
|
||||
digraph peer_states {
|
||||
Secondary -> Primary [ label = "recv state packet" ]
|
||||
Primary -> Secondary [ label = "recv state packet" ]
|
||||
Primary -> Unknown [ label = "connection lost" ]
|
||||
Secondary -> Unknown [ label = "connection lost" ]
|
||||
Unknown -> Primary [ label = "connected" ]
|
||||
Unknown -> Secondary [ label = "connected" ]
|
||||
}
|
||||
|
||||
|
|
@ -0,0 +1,135 @@
|
|||
Block IO Controller
|
||||
===================
|
||||
Overview
|
||||
========
|
||||
cgroup subsys "blkio" implements the block io controller. There seems to be
|
||||
a need of various kinds of IO control policies (like proportional BW, max BW)
|
||||
both at leaf nodes as well as at intermediate nodes in a storage hierarchy.
|
||||
Plan is to use the same cgroup based management interface for blkio controller
|
||||
and based on user options switch IO policies in the background.
|
||||
|
||||
In the first phase, this patchset implements proportional weight time based
|
||||
division of disk policy. It is implemented in CFQ. Hence this policy takes
|
||||
effect only on leaf nodes when CFQ is being used.
|
||||
|
||||
HOWTO
|
||||
=====
|
||||
You can do a very simple testing of running two dd threads in two different
|
||||
cgroups. Here is what you can do.
|
||||
|
||||
- Enable group scheduling in CFQ
|
||||
CONFIG_CFQ_GROUP_IOSCHED=y
|
||||
|
||||
- Compile and boot into kernel and mount IO controller (blkio).
|
||||
|
||||
mount -t cgroup -o blkio none /cgroup
|
||||
|
||||
- Create two cgroups
|
||||
mkdir -p /cgroup/test1/ /cgroup/test2
|
||||
|
||||
- Set weights of group test1 and test2
|
||||
echo 1000 > /cgroup/test1/blkio.weight
|
||||
echo 500 > /cgroup/test2/blkio.weight
|
||||
|
||||
- Create two same size files (say 512MB each) on same disk (file1, file2) and
|
||||
launch two dd threads in different cgroup to read those files.
|
||||
|
||||
sync
|
||||
echo 3 > /proc/sys/vm/drop_caches
|
||||
|
||||
dd if=/mnt/sdb/zerofile1 of=/dev/null &
|
||||
echo $! > /cgroup/test1/tasks
|
||||
cat /cgroup/test1/tasks
|
||||
|
||||
dd if=/mnt/sdb/zerofile2 of=/dev/null &
|
||||
echo $! > /cgroup/test2/tasks
|
||||
cat /cgroup/test2/tasks
|
||||
|
||||
- At macro level, first dd should finish first. To get more precise data, keep
|
||||
on looking at (with the help of script), at blkio.disk_time and
|
||||
blkio.disk_sectors files of both test1 and test2 groups. This will tell how
|
||||
much disk time (in milli seconds), each group got and how many secotors each
|
||||
group dispatched to the disk. We provide fairness in terms of disk time, so
|
||||
ideally io.disk_time of cgroups should be in proportion to the weight.
|
||||
|
||||
Various user visible config options
|
||||
===================================
|
||||
CONFIG_CFQ_GROUP_IOSCHED
|
||||
- Enables group scheduling in CFQ. Currently only 1 level of group
|
||||
creation is allowed.
|
||||
|
||||
CONFIG_DEBUG_CFQ_IOSCHED
|
||||
- Enables some debugging messages in blktrace. Also creates extra
|
||||
cgroup file blkio.dequeue.
|
||||
|
||||
Config options selected automatically
|
||||
=====================================
|
||||
These config options are not user visible and are selected/deselected
|
||||
automatically based on IO scheduler configuration.
|
||||
|
||||
CONFIG_BLK_CGROUP
|
||||
- Block IO controller. Selected by CONFIG_CFQ_GROUP_IOSCHED.
|
||||
|
||||
CONFIG_DEBUG_BLK_CGROUP
|
||||
- Debug help. Selected by CONFIG_DEBUG_CFQ_IOSCHED.
|
||||
|
||||
Details of cgroup files
|
||||
=======================
|
||||
- blkio.weight
|
||||
- Specifies per cgroup weight.
|
||||
|
||||
Currently allowed range of weights is from 100 to 1000.
|
||||
|
||||
- blkio.time
|
||||
- disk time allocated to cgroup per device in milliseconds. First
|
||||
two fields specify the major and minor number of the device and
|
||||
third field specifies the disk time allocated to group in
|
||||
milliseconds.
|
||||
|
||||
- blkio.sectors
|
||||
- number of sectors transferred to/from disk by the group. First
|
||||
two fields specify the major and minor number of the device and
|
||||
third field specifies the number of sectors transferred by the
|
||||
group to/from the device.
|
||||
|
||||
- blkio.dequeue
|
||||
- Debugging aid only enabled if CONFIG_DEBUG_CFQ_IOSCHED=y. This
|
||||
gives the statistics about how many a times a group was dequeued
|
||||
from service tree of the device. First two fields specify the major
|
||||
and minor number of the device and third field specifies the number
|
||||
of times a group was dequeued from a particular device.
|
||||
|
||||
CFQ sysfs tunable
|
||||
=================
|
||||
/sys/block/<disk>/queue/iosched/group_isolation
|
||||
|
||||
If group_isolation=1, it provides stronger isolation between groups at the
|
||||
expense of throughput. By default group_isolation is 0. In general that
|
||||
means that if group_isolation=0, expect fairness for sequential workload
|
||||
only. Set group_isolation=1 to see fairness for random IO workload also.
|
||||
|
||||
Generally CFQ will put random seeky workload in sync-noidle category. CFQ
|
||||
will disable idling on these queues and it does a collective idling on group
|
||||
of such queues. Generally these are slow moving queues and if there is a
|
||||
sync-noidle service tree in each group, that group gets exclusive access to
|
||||
disk for certain period. That means it will bring the throughput down if
|
||||
group does not have enough IO to drive deeper queue depths and utilize disk
|
||||
capacity to the fullest in the slice allocated to it. But the flip side is
|
||||
that even a random reader should get better latencies and overall throughput
|
||||
if there are lots of sequential readers/sync-idle workload running in the
|
||||
system.
|
||||
|
||||
If group_isolation=0, then CFQ automatically moves all the random seeky queues
|
||||
in the root group. That means there will be no service differentiation for
|
||||
that kind of workload. This leads to better throughput as we do collective
|
||||
idling on root sync-noidle tree.
|
||||
|
||||
By default one should run with group_isolation=0. If that is not sufficient
|
||||
and one wants stronger isolation between groups, then set group_isolation=1
|
||||
but this will come at cost of reduced throughput.
|
||||
|
||||
What works
|
||||
==========
|
||||
- Currently only sync IO queues are support. All the buffered writes are
|
||||
still system wide and not per group. Hence we will not see service
|
||||
differentiation between buffered writes between groups.
|
||||
|
|
@ -65,6 +65,7 @@ aicdb.h*
|
|||
asm-offsets.h
|
||||
asm_offsets.h
|
||||
autoconf.h*
|
||||
av_permissions.h
|
||||
bbootsect
|
||||
bin2c
|
||||
binkernel.spec
|
||||
|
|
@ -95,12 +96,14 @@ docproc
|
|||
elf2ecoff
|
||||
elfconfig.h*
|
||||
fixdep
|
||||
flask.h
|
||||
fore200e_mkfirm
|
||||
fore200e_pca_fw.c*
|
||||
gconf
|
||||
gen-devlist
|
||||
gen_crc32table
|
||||
gen_init_cpio
|
||||
genheaders
|
||||
genksyms
|
||||
*_gray256.c
|
||||
ihex2fw
|
||||
|
|
|
|||
|
|
@ -85,7 +85,7 @@ http://www.linuxtv.org/wiki/index.php/DVB_USB
|
|||
- moved transfer control (pid filter, fifo control) from usb driver to frontend, it seems
|
||||
better settled there (added xfer_ops-struct)
|
||||
- created a common files for frontends (mc/p/mb)
|
||||
2004-09-28 - added support for a new device (Unkown, vendor ID is Hyper-Paltek)
|
||||
2004-09-28 - added support for a new device (Unknown, vendor ID is Hyper-Paltek)
|
||||
2004-09-20 - added support for a new device (Compro DVB-U2000), thanks
|
||||
to Amaury Demol for reporting
|
||||
- changed usb TS transfer method (several urbs, stopping transfer
|
||||
|
|
|
|||
|
|
@ -80,7 +80,7 @@ is:
|
|||
|
||||
broken_parity_status
|
||||
|
||||
as is located in /sys/devices/pci<XXX>/0000:XX:YY.Z directorys for
|
||||
as is located in /sys/devices/pci<XXX>/0000:XX:YY.Z directories for
|
||||
PCI devices.
|
||||
|
||||
FUTURE HARDWARE SCANNING
|
||||
|
|
@ -288,9 +288,8 @@ Total UE count that had no information attribute fileY:
|
|||
|
||||
'ue_noinfo_count'
|
||||
|
||||
This attribute file displays the number of UEs that
|
||||
have occurred have occurred with no informations as to which DIMM
|
||||
slot is having errors.
|
||||
This attribute file displays the number of UEs that have occurred
|
||||
with no information as to which DIMM slot is having errors.
|
||||
|
||||
|
||||
Total Correctable Errors count attribute file:
|
||||
|
|
|
|||
|
|
@ -312,10 +312,8 @@ and to the following documentation:
|
|||
8. Mailing list
|
||||
---------------
|
||||
|
||||
There are several frame buffer device related mailing lists at SourceForge:
|
||||
- linux-fbdev-announce@lists.sourceforge.net, for announcements,
|
||||
- linux-fbdev-user@lists.sourceforge.net, for generic user support,
|
||||
- linux-fbdev-devel@lists.sourceforge.net, for project developers.
|
||||
There is a frame buffer device related mailing list at kernel.org:
|
||||
linux-fbdev@vger.kernel.org.
|
||||
|
||||
Point your web browser to http://sourceforge.net/projects/linux-fbdev/ for
|
||||
subscription information and archive browsing.
|
||||
|
|
|
|||
|
|
@ -6,6 +6,21 @@ be removed from this file.
|
|||
|
||||
---------------------------
|
||||
|
||||
What: USER_SCHED
|
||||
When: 2.6.34
|
||||
|
||||
Why: USER_SCHED was implemented as a proof of concept for group scheduling.
|
||||
The effect of USER_SCHED can already be achieved from userspace with
|
||||
the help of libcgroup. The removal of USER_SCHED will also simplify
|
||||
the scheduler code with the removal of one major ifdef. There are also
|
||||
issues USER_SCHED has with USER_NS. A decision was taken not to fix
|
||||
those and instead remove USER_SCHED. Also new group scheduling
|
||||
features will not be implemented for USER_SCHED.
|
||||
|
||||
Who: Dhaval Giani <dhaval@linux.vnet.ibm.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: PRISM54
|
||||
When: 2.6.34
|
||||
|
||||
|
|
@ -302,18 +317,6 @@ Who: ocfs2-devel@oss.oracle.com
|
|||
|
||||
---------------------------
|
||||
|
||||
What: SCTP_GET_PEER_ADDRS_NUM_OLD, SCTP_GET_PEER_ADDRS_OLD,
|
||||
SCTP_GET_LOCAL_ADDRS_NUM_OLD, SCTP_GET_LOCAL_ADDRS_OLD
|
||||
When: June 2009
|
||||
Why: A newer version of the options have been introduced in 2005 that
|
||||
removes the limitions of the old API. The sctp library has been
|
||||
converted to use these new options at the same time. Any user
|
||||
space app that directly uses the old options should convert to using
|
||||
the new options.
|
||||
Who: Vlad Yasevich <vladislav.yasevich@hp.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: Ability for non root users to shm_get hugetlb pages based on mlock
|
||||
resource limits
|
||||
When: 2.6.31
|
||||
|
|
@ -404,15 +407,6 @@ Who: Alex Chiang <achiang@hp.com>
|
|||
|
||||
---------------------------
|
||||
|
||||
What: i2c-voodoo3 driver
|
||||
When: October 2009
|
||||
Why: Superseded by tdfxfb. I2C/DDC support used to live in a separate
|
||||
driver but this caused driver conflicts.
|
||||
Who: Jean Delvare <khali@linux-fr.org>
|
||||
Krzysztof Helt <krzysztof.h1@wp.pl>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: CONFIG_RFKILL_INPUT
|
||||
When: 2.6.33
|
||||
Why: Should be implemented in userspace, policy daemon.
|
||||
|
|
@ -489,3 +483,10 @@ Why: With the recent innovations in CPU hardware acceleration technologies
|
|||
Who: Alok N Kataria <akataria@vmware.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: adt7473 hardware monitoring driver
|
||||
When: February 2010
|
||||
Why: Obsoleted by the adt7475 driver.
|
||||
Who: Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
---------------------------
|
||||
|
|
|
|||
|
|
@ -235,6 +235,7 @@ proc files.
|
|||
neg=N Number of negative lookups made
|
||||
pos=N Number of positive lookups made
|
||||
crt=N Number of objects created by lookup
|
||||
tmo=N Number of lookups timed out and requeued
|
||||
Updates n=N Number of update cookie requests seen
|
||||
nul=N Number of upd reqs given a NULL parent
|
||||
run=N Number of upd reqs granted CPU time
|
||||
|
|
@ -250,8 +251,10 @@ proc files.
|
|||
ok=N Number of successful alloc reqs
|
||||
wt=N Number of alloc reqs that waited on lookup completion
|
||||
nbf=N Number of alloc reqs rejected -ENOBUFS
|
||||
int=N Number of alloc reqs aborted -ERESTARTSYS
|
||||
ops=N Number of alloc reqs submitted
|
||||
owt=N Number of alloc reqs waited for CPU time
|
||||
abt=N Number of alloc reqs aborted due to object death
|
||||
Retrvls n=N Number of retrieval (read) requests seen
|
||||
ok=N Number of successful retr reqs
|
||||
wt=N Number of retr reqs that waited on lookup completion
|
||||
|
|
@ -261,6 +264,7 @@ proc files.
|
|||
oom=N Number of retr reqs failed -ENOMEM
|
||||
ops=N Number of retr reqs submitted
|
||||
owt=N Number of retr reqs waited for CPU time
|
||||
abt=N Number of retr reqs aborted due to object death
|
||||
Stores n=N Number of storage (write) requests seen
|
||||
ok=N Number of successful store reqs
|
||||
agn=N Number of store reqs on a page already pending storage
|
||||
|
|
@ -268,12 +272,37 @@ proc files.
|
|||
oom=N Number of store reqs failed -ENOMEM
|
||||
ops=N Number of store reqs submitted
|
||||
run=N Number of store reqs granted CPU time
|
||||
pgs=N Number of pages given store req processing time
|
||||
rxd=N Number of store reqs deleted from tracking tree
|
||||
olm=N Number of store reqs over store limit
|
||||
VmScan nos=N Number of release reqs against pages with no pending store
|
||||
gon=N Number of release reqs against pages stored by time lock granted
|
||||
bsy=N Number of release reqs ignored due to in-progress store
|
||||
can=N Number of page stores cancelled due to release req
|
||||
Ops pend=N Number of times async ops added to pending queues
|
||||
run=N Number of times async ops given CPU time
|
||||
enq=N Number of times async ops queued for processing
|
||||
can=N Number of async ops cancelled
|
||||
rej=N Number of async ops rejected due to object lookup/create failure
|
||||
dfr=N Number of async ops queued for deferred release
|
||||
rel=N Number of async ops released
|
||||
gc=N Number of deferred-release async ops garbage collected
|
||||
CacheOp alo=N Number of in-progress alloc_object() cache ops
|
||||
luo=N Number of in-progress lookup_object() cache ops
|
||||
luc=N Number of in-progress lookup_complete() cache ops
|
||||
gro=N Number of in-progress grab_object() cache ops
|
||||
upo=N Number of in-progress update_object() cache ops
|
||||
dro=N Number of in-progress drop_object() cache ops
|
||||
pto=N Number of in-progress put_object() cache ops
|
||||
syn=N Number of in-progress sync_cache() cache ops
|
||||
atc=N Number of in-progress attr_changed() cache ops
|
||||
rap=N Number of in-progress read_or_alloc_page() cache ops
|
||||
ras=N Number of in-progress read_or_alloc_pages() cache ops
|
||||
alp=N Number of in-progress allocate_page() cache ops
|
||||
als=N Number of in-progress allocate_pages() cache ops
|
||||
wrp=N Number of in-progress write_page() cache ops
|
||||
ucp=N Number of in-progress uncache_page() cache ops
|
||||
dsp=N Number of in-progress dissociate_pages() cache ops
|
||||
|
||||
|
||||
(*) /proc/fs/fscache/histogram
|
||||
|
|
@ -299,6 +328,87 @@ proc files.
|
|||
jiffy range covered, and the SECS field the equivalent number of seconds.
|
||||
|
||||
|
||||
===========
|
||||
OBJECT LIST
|
||||
===========
|
||||
|
||||
If CONFIG_FSCACHE_OBJECT_LIST is enabled, the FS-Cache facility will maintain a
|
||||
list of all the objects currently allocated and allow them to be viewed
|
||||
through:
|
||||
|
||||
/proc/fs/fscache/objects
|
||||
|
||||
This will look something like:
|
||||
|
||||
[root@andromeda ~]# head /proc/fs/fscache/objects
|
||||
OBJECT PARENT STAT CHLDN OPS OOP IPR EX READS EM EV F S | NETFS_COOKIE_DEF TY FL NETFS_DATA OBJECT_KEY, AUX_DATA
|
||||
======== ======== ==== ===== === === === == ===== == == = = | ================ == == ================ ================
|
||||
17e4b 2 ACTV 0 0 0 0 0 0 7b 4 0 8 | NFS.fh DT 0 ffff88001dd82820 010006017edcf8bbc93b43298fdfbe71e50b57b13a172c0117f38472, e567634700000000000000000000000063f2404a000000000000000000000000c9030000000000000000000063f2404a
|
||||
1693a 2 ACTV 0 0 0 0 0 0 7b 4 0 8 | NFS.fh DT 0 ffff88002db23380 010006017edcf8bbc93b43298fdfbe71e50b57b1e0162c01a2df0ea6, 420ebc4a000000000000000000000000420ebc4a0000000000000000000000000e1801000000000000000000420ebc4a
|
||||
|
||||
where the first set of columns before the '|' describe the object:
|
||||
|
||||
COLUMN DESCRIPTION
|
||||
======= ===============================================================
|
||||
OBJECT Object debugging ID (appears as OBJ%x in some debug messages)
|
||||
PARENT Debugging ID of parent object
|
||||
STAT Object state
|
||||
CHLDN Number of child objects of this object
|
||||
OPS Number of outstanding operations on this object
|
||||
OOP Number of outstanding child object management operations
|
||||
IPR
|
||||
EX Number of outstanding exclusive operations
|
||||
READS Number of outstanding read operations
|
||||
EM Object's event mask
|
||||
EV Events raised on this object
|
||||
F Object flags
|
||||
S Object slow-work work item flags
|
||||
|
||||
and the second set of columns describe the object's cookie, if present:
|
||||
|
||||
COLUMN DESCRIPTION
|
||||
=============== =======================================================
|
||||
NETFS_COOKIE_DEF Name of netfs cookie definition
|
||||
TY Cookie type (IX - index, DT - data, hex - special)
|
||||
FL Cookie flags
|
||||
NETFS_DATA Netfs private data stored in the cookie
|
||||
OBJECT_KEY Object key } 1 column, with separating comma
|
||||
AUX_DATA Object aux data } presence may be configured
|
||||
|
||||
The data shown may be filtered by attaching the a key to an appropriate keyring
|
||||
before viewing the file. Something like:
|
||||
|
||||
keyctl add user fscache:objlist <restrictions> @s
|
||||
|
||||
where <restrictions> are a selection of the following letters:
|
||||
|
||||
K Show hexdump of object key (don't show if not given)
|
||||
A Show hexdump of object aux data (don't show if not given)
|
||||
|
||||
and the following paired letters:
|
||||
|
||||
C Show objects that have a cookie
|
||||
c Show objects that don't have a cookie
|
||||
B Show objects that are busy
|
||||
b Show objects that aren't busy
|
||||
W Show objects that have pending writes
|
||||
w Show objects that don't have pending writes
|
||||
R Show objects that have outstanding reads
|
||||
r Show objects that don't have outstanding reads
|
||||
S Show objects that have slow work queued
|
||||
s Show objects that don't have slow work queued
|
||||
|
||||
If neither side of a letter pair is given, then both are implied. For example:
|
||||
|
||||
keyctl add user fscache:objlist KB @s
|
||||
|
||||
shows objects that are busy, and lists their object keys, but does not dump
|
||||
their auxiliary data. It also implies "CcWwRrSs", but as 'B' is given, 'b' is
|
||||
not implied.
|
||||
|
||||
By default all objects and all fields will be shown.
|
||||
|
||||
|
||||
=========
|
||||
DEBUGGING
|
||||
=========
|
||||
|
|
|
|||
|
|
@ -641,7 +641,7 @@ data file must be retired (see the relinquish cookie function below).
|
|||
|
||||
Furthermore, note that this does not cancel the asynchronous read or write
|
||||
operation started by the read/alloc and write functions, so the page
|
||||
invalidation and release functions must use:
|
||||
invalidation functions must use:
|
||||
|
||||
bool fscache_check_page_write(struct fscache_cookie *cookie,
|
||||
struct page *page);
|
||||
|
|
@ -654,6 +654,25 @@ to see if a page is being written to the cache, and:
|
|||
to wait for it to finish if it is.
|
||||
|
||||
|
||||
When releasepage() is being implemented, a special FS-Cache function exists to
|
||||
manage the heuristics of coping with vmscan trying to eject pages, which may
|
||||
conflict with the cache trying to write pages to the cache (which may itself
|
||||
need to allocate memory):
|
||||
|
||||
bool fscache_maybe_release_page(struct fscache_cookie *cookie,
|
||||
struct page *page,
|
||||
gfp_t gfp);
|
||||
|
||||
This takes the netfs cookie, and the page and gfp arguments as supplied to
|
||||
releasepage(). It will return false if the page cannot be released yet for
|
||||
some reason and if it returns true, the page has been uncached and can now be
|
||||
released.
|
||||
|
||||
To make a page available for release, this function may wait for an outstanding
|
||||
storage request to complete, or it may attempt to cancel the storage request -
|
||||
in which case the page will not be stored in the cache this time.
|
||||
|
||||
|
||||
==========================
|
||||
INDEX AND DATA FILE UPDATE
|
||||
==========================
|
||||
|
|
|
|||
|
|
@ -20,15 +20,16 @@ Lots of code taken from ext3 and other projects.
|
|||
Authors in alphabetical order:
|
||||
Joel Becker <joel.becker@oracle.com>
|
||||
Zach Brown <zach.brown@oracle.com>
|
||||
Mark Fasheh <mark.fasheh@oracle.com>
|
||||
Mark Fasheh <mfasheh@suse.com>
|
||||
Kurt Hackel <kurt.hackel@oracle.com>
|
||||
Tao Ma <tao.ma@oracle.com>
|
||||
Sunil Mushran <sunil.mushran@oracle.com>
|
||||
Manish Singh <manish.singh@oracle.com>
|
||||
Tiger Yang <tiger.yang@oracle.com>
|
||||
|
||||
Caveats
|
||||
=======
|
||||
Features which OCFS2 does not support yet:
|
||||
- quotas
|
||||
- Directory change notification (F_NOTIFY)
|
||||
- Distributed Caching (F_SETLEASE/F_GETLEASE/break_lease)
|
||||
|
||||
|
|
@ -70,7 +71,6 @@ commit=nrsec (*) Ocfs2 can be told to sync all its data and metadata
|
|||
performance.
|
||||
localalloc=8(*) Allows custom localalloc size in MB. If the value is too
|
||||
large, the fs will silently revert it to the default.
|
||||
Localalloc is not enabled for local mounts.
|
||||
localflocks This disables cluster aware flock.
|
||||
inode64 Indicates that Ocfs2 is allowed to create inodes at
|
||||
any location in the filesystem, including those which
|
||||
|
|
|
|||
|
|
@ -1072,7 +1072,8 @@ second). The meanings of the columns are as follows, from left to right:
|
|||
- irq: servicing interrupts
|
||||
- softirq: servicing softirqs
|
||||
- steal: involuntary wait
|
||||
- guest: running a guest
|
||||
- guest: running a normal guest
|
||||
- guest_nice: running a niced guest
|
||||
|
||||
The "intr" line gives counts of interrupts serviced since boot time, for each
|
||||
of the possible system interrupts. The first column is the total of all
|
||||
|
|
@ -1088,8 +1089,8 @@ The "processes" line gives the number of processes and threads created, which
|
|||
includes (but is not limited to) those created by calls to the fork() and
|
||||
clone() system calls.
|
||||
|
||||
The "procs_running" line gives the number of processes currently running on
|
||||
CPUs.
|
||||
The "procs_running" line gives the total number of threads that are
|
||||
running or ready to run (i.e., the total number of runnable threads).
|
||||
|
||||
The "procs_blocked" line gives the number of processes currently blocked,
|
||||
waiting for I/O to complete.
|
||||
|
|
|
|||
|
|
@ -380,7 +380,7 @@ rare; use gpiochip_remove() when it is unavoidable.
|
|||
|
||||
Most often a gpio_chip is part of an instance-specific structure with state
|
||||
not exposed by the GPIO interfaces, such as addressing, power management,
|
||||
and more. Chips such as codecs will have complex non-GPIO state,
|
||||
and more. Chips such as codecs will have complex non-GPIO state.
|
||||
|
||||
Any debugfs dump method should normally ignore signals which haven't been
|
||||
requested as GPIOs. They can use gpiochip_is_requested(), which returns
|
||||
|
|
@ -531,7 +531,7 @@ and have the following read/write attributes:
|
|||
This file exists only if the pin can be configured as an
|
||||
interrupt generating input pin.
|
||||
|
||||
GPIO controllers have paths like /sys/class/gpio/chipchip42/ (for the
|
||||
GPIO controllers have paths like /sys/class/gpio/gpiochip42/ (for the
|
||||
controller implementing GPIOs starting at #42) and have the following
|
||||
read-only attributes:
|
||||
|
||||
|
|
|
|||
|
|
@ -9,6 +9,8 @@ Supported chips:
|
|||
|
||||
Author: Darrick J. Wong
|
||||
|
||||
This driver is depreacted, please use the adt7475 driver instead.
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
|
|
|
|||
|
|
@ -1,87 +1,117 @@
|
|||
This describes the interface for the ADT7475 driver:
|
||||
Kernel driver adt7475
|
||||
=====================
|
||||
|
||||
(there are 4 fans, numbered fan1 to fan4):
|
||||
Supported chips:
|
||||
* Analog Devices ADT7473
|
||||
Prefix: 'adt7473'
|
||||
Addresses scanned: I2C 0x2C, 0x2D, 0x2E
|
||||
Datasheet: Publicly available at the On Semiconductors website
|
||||
* Analog Devices ADT7475
|
||||
Prefix: 'adt7475'
|
||||
Addresses scanned: I2C 0x2E
|
||||
Datasheet: Publicly available at the On Semiconductors website
|
||||
* Analog Devices ADT7476
|
||||
Prefix: 'adt7476'
|
||||
Addresses scanned: I2C 0x2C, 0x2D, 0x2E
|
||||
Datasheet: Publicly available at the On Semiconductors website
|
||||
* Analog Devices ADT7490
|
||||
Prefix: 'adt7490'
|
||||
Addresses scanned: I2C 0x2C, 0x2D, 0x2E
|
||||
Datasheet: Publicly available at the On Semiconductors website
|
||||
|
||||
fanX_input Read the current speed of the fan (in RPMs)
|
||||
fanX_min Read/write the minimum speed of the fan. Dropping
|
||||
below this sets an alarm.
|
||||
Authors:
|
||||
Jordan Crouse
|
||||
Hans de Goede
|
||||
Darrick J. Wong (documentation)
|
||||
Jean Delvare
|
||||
|
||||
(there are three PWMs, numbered pwm1 to pwm3):
|
||||
|
||||
pwmX Read/write the current duty cycle of the PWM. Writes
|
||||
only have effect when auto mode is turned off (see
|
||||
below). Range is 0 - 255.
|
||||
Description
|
||||
-----------
|
||||
|
||||
pwmX_enable Fan speed control method:
|
||||
This driver implements support for the Analog Devices ADT7473, ADT7475,
|
||||
ADT7476 and ADT7490 chip family. The ADT7473 and ADT7475 differ only in
|
||||
minor details. The ADT7476 has additional features, including extra voltage
|
||||
measurement inputs and VID support. The ADT7490 also has additional
|
||||
features, including extra voltage measurement inputs and PECI support. All
|
||||
the supported chips will be collectively designed by the name "ADT747x" in
|
||||
the rest of this document.
|
||||
|
||||
0 - No control (fan at full speed)
|
||||
1 - Manual fan speed control (using pwm[1-*])
|
||||
2 - Automatic fan speed control
|
||||
The ADT747x uses the 2-wire interface compatible with the SMBus 2.0
|
||||
specification. Using an analog to digital converter it measures three (3)
|
||||
temperatures and two (2) or more voltages. It has four (4) 16-bit counters
|
||||
for measuring fan speed. There are three (3) PWM outputs that can be used
|
||||
to control fan speed.
|
||||
|
||||
pwmX_auto_channels_temp Select which channels affect this PWM
|
||||
A sophisticated control system for the PWM outputs is designed into the
|
||||
ADT747x that allows fan speed to be adjusted automatically based on any of the
|
||||
three temperature sensors. Each PWM output is individually adjustable and
|
||||
programmable. Once configured, the ADT747x will adjust the PWM outputs in
|
||||
response to the measured temperatures without further host intervention.
|
||||
This feature can also be disabled for manual control of the PWM's.
|
||||
|
||||
1 - TEMP1 controls PWM
|
||||
2 - TEMP2 controls PWM
|
||||
4 - TEMP3 controls PWM
|
||||
6 - TEMP2 and TEMP3 control PWM
|
||||
7 - All three inputs control PWM
|
||||
Each of the measured inputs (voltage, temperature, fan speed) has
|
||||
corresponding high/low limit values. The ADT747x will signal an ALARM if
|
||||
any measured value exceeds either limit.
|
||||
|
||||
pwmX_freq Read/write the PWM frequency in Hz. The number
|
||||
should be one of the following:
|
||||
The ADT747x samples all inputs continuously. The driver will not read
|
||||
the registers more often than once every other second. Further,
|
||||
configuration data is only read once per minute.
|
||||
|
||||
11 Hz
|
||||
14 Hz
|
||||
22 Hz
|
||||
29 Hz
|
||||
35 Hz
|
||||
44 Hz
|
||||
58 Hz
|
||||
88 Hz
|
||||
Chip Differences Summary
|
||||
------------------------
|
||||
|
||||
pwmX_auto_point1_pwm Read/write the minimum PWM duty cycle in automatic mode
|
||||
ADT7473:
|
||||
* 2 voltage inputs
|
||||
* system acoustics optimizations (not implemented)
|
||||
|
||||
pwmX_auto_point2_pwm Read/write the maximum PWM duty cycle in automatic mode
|
||||
ADT7475:
|
||||
* 2 voltage inputs
|
||||
|
||||
(there are three temperature settings numbered temp1 to temp3):
|
||||
ADT7476:
|
||||
* 5 voltage inputs
|
||||
* VID support
|
||||
|
||||
tempX_input Read the current temperature. The value is in milli
|
||||
degrees of Celsius.
|
||||
ADT7490:
|
||||
* 6 voltage inputs
|
||||
* 1 Imon input (not implemented)
|
||||
* PECI support (not implemented)
|
||||
* 2 GPIO pins (not implemented)
|
||||
* system acoustics optimizations (not implemented)
|
||||
|
||||
tempX_max Read/write the upper temperature limit - exceeding this
|
||||
will cause an alarm.
|
||||
Special Features
|
||||
----------------
|
||||
|
||||
tempX_min Read/write the lower temperature limit - exceeding this
|
||||
will cause an alarm.
|
||||
The ADT747x has a 10-bit ADC and can therefore measure temperatures
|
||||
with a resolution of 0.25 degree Celsius. Temperature readings can be
|
||||
configured either for two's complement format or "Offset 64" format,
|
||||
wherein 64 is subtracted from the raw value to get the temperature value.
|
||||
|
||||
tempX_offset Read/write the temperature adjustment offset
|
||||
The datasheet is very detailed and describes a procedure for determining
|
||||
an optimal configuration for the automatic PWM control.
|
||||
|
||||
tempX_crit Read/write the THERM limit for remote1.
|
||||
Fan Speed Control
|
||||
-----------------
|
||||
|
||||
tempX_crit_hyst Set the temperature value below crit where the
|
||||
fans will stay on - this helps drive the temperature
|
||||
low enough so it doesn't stay near the edge and
|
||||
cause THERM to keep tripping.
|
||||
The driver exposes two trip points per PWM channel.
|
||||
|
||||
tempX_auto_point1_temp Read/write the minimum temperature where the fans will
|
||||
turn on in automatic mode.
|
||||
point1: Set the PWM speed at the lower temperature bound
|
||||
point2: Set the PWM speed at the higher temperature bound
|
||||
|
||||
tempX_auto_point2_temp Read/write the maximum temperature over which the fans
|
||||
will run in automatic mode. tempX_auto_point1_temp
|
||||
and tempX_auto_point2_temp together define the
|
||||
range of automatic control.
|
||||
The ADT747x will scale the PWM linearly between the lower and higher PWM
|
||||
speed when the temperature is between the two temperature boundaries.
|
||||
Temperature boundaries are associated to temperature channels rather than
|
||||
PWM outputs, and a given PWM output can be controlled by several temperature
|
||||
channels. As a result, the ADT747x may compute more than one PWM value
|
||||
for a channel at a given time, in which case the maximum value (fastest
|
||||
fan speed) is applied. PWM values range from 0 (off) to 255 (full speed).
|
||||
|
||||
tempX_alarm Read a 1 if the max/min alarm is set
|
||||
tempX_fault Read a 1 if either temp1 or temp3 diode has a fault
|
||||
Fan speed may be set to maximum when the temperature sensor associated with
|
||||
the PWM control exceeds temp#_max.
|
||||
|
||||
(There are two voltage settings, in1 and in2):
|
||||
Notes
|
||||
-----
|
||||
|
||||
inX_input Read the current voltage on VCC. Value is in
|
||||
millivolts.
|
||||
|
||||
inX_min read/write the minimum voltage limit.
|
||||
Dropping below this causes an alarm.
|
||||
|
||||
inX_max read/write the maximum voltage limit.
|
||||
Exceeding this causes an alarm.
|
||||
|
||||
inX_alarm Read a 1 if the max/min alarm is set.
|
||||
The nVidia binary driver presents an ADT7473 chip via an on-card i2c bus.
|
||||
Unfortunately, they fail to set the i2c adapter class, so this driver may
|
||||
fail to find the chip until the nvidia driver is patched.
|
||||
|
|
|
|||
|
|
@ -14,6 +14,10 @@ Supported chips:
|
|||
Prefix: 'f71882fg'
|
||||
Addresses scanned: none, address read from Super I/O config space
|
||||
Datasheet: Available from the Fintek website
|
||||
* Fintek F71889FG
|
||||
Prefix: 'f71889fg'
|
||||
Addresses scanned: none, address read from Super I/O config space
|
||||
Datasheet: Should become available on the Fintek website soon
|
||||
* Fintek F8000
|
||||
Prefix: 'f8000'
|
||||
Addresses scanned: none, address read from Super I/O config space
|
||||
|
|
@ -51,6 +55,12 @@ supported. The right one to use depends on external circuitry on the
|
|||
motherboard, so the driver assumes that the BIOS set the method
|
||||
properly.
|
||||
|
||||
Note that the lowest numbered temperature zone trip point corresponds to
|
||||
to the border between the highest and one but highest temperature zones, and
|
||||
vica versa. So the temperature zone trip points 1-4 (or 1-2) go from high temp
|
||||
to low temp! This is how things are implemented in the IC, and the driver
|
||||
mimicks this.
|
||||
|
||||
There are 2 modes to specify the speed of the fan, PWM duty cycle (or DC
|
||||
voltage) mode, where 0-100% duty cycle (0-100% of 12V) is specified. And RPM
|
||||
mode where the actual RPM of the fan (as measured) is controlled and the speed
|
||||
|
|
|
|||
|
|
@ -86,7 +86,6 @@ The IT8712F and IT8716F additionally feature VID inputs, used to report
|
|||
the Vcore voltage of the processor. The early IT8712F have 5 VID pins,
|
||||
the IT8716F and late IT8712F have 6. They are shared with other functions
|
||||
though, so the functionality may not be available on a given system.
|
||||
The driver dumbly assume it is there.
|
||||
|
||||
The IT8718F and IT8720F also features VID inputs (up to 8 pins) but the value
|
||||
is stored in the Super-I/O configuration space. Due to technical limitations,
|
||||
|
|
|
|||
|
|
@ -0,0 +1,50 @@
|
|||
Kernel driver mc13783-adc
|
||||
=========================
|
||||
|
||||
Supported chips:
|
||||
* Freescale Atlas MC13783
|
||||
Prefix: 'mc13783_adc'
|
||||
Datasheet: http://www.freescale.com/files/rf_if/doc/data_sheet/MC13783.pdf?fsrch=1
|
||||
|
||||
Authors:
|
||||
Sascha Hauer <s.hauer@pengutronix.de>
|
||||
Luotao Fu <l.fu@pengutronix.de>
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
The Freescale MC13783 is a Power Management and Audio Circuit. Among
|
||||
other things it contains a 10-bit A/D converter. The converter has 16
|
||||
channels which can be used in different modes.
|
||||
The A/D converter has a resolution of 2.25mV. Channels 0-4 have
|
||||
a dedicated meaning with chip internal scaling applied. Channels 5-7
|
||||
can be used as general purpose inputs or alternatively in a dedicated
|
||||
mode. Channels 12-15 are occupied by the touchscreen if it's active.
|
||||
|
||||
Currently the driver only supports channels 2 and 5-15 with no alternative
|
||||
modes for channels 5-7.
|
||||
|
||||
See this table for the meaning of the different channels and their chip
|
||||
internal scaling:
|
||||
|
||||
Channel Signal Input Range Scaling
|
||||
-------------------------------------------------------------------------------
|
||||
0 Battery Voltage (BATT) 2.50 - 4.65V -2.40V
|
||||
1 Battery Current (BATT - BATTISNS) -50 - 50 mV x20
|
||||
2 Application Supply (BP) 2.50 - 4.65V -2.40V
|
||||
3 Charger Voltage (CHRGRAW) 0 - 10V / /5
|
||||
0 - 20V /10
|
||||
4 Charger Current (CHRGISNSP-CHRGISNSN) -0.25V - 0.25V x4
|
||||
5 General Purpose ADIN5 / Battery Pack Thermistor 0 - 2.30V No
|
||||
6 General Purpose ADIN6 / Backup Voltage (LICELL) 0 - 2.30V / No /
|
||||
1.50 - 3.50V -1.20V
|
||||
7 General Purpose ADIN7 / UID / Die Temperature 0 - 2.30V / No /
|
||||
0 - 2.55V / x0.9 / No
|
||||
8 General Purpose ADIN8 0 - 2.30V No
|
||||
9 General Purpose ADIN9 0 - 2.30V No
|
||||
10 General Purpose ADIN10 0 - 2.30V No
|
||||
11 General Purpose ADIN11 0 - 2.30V No
|
||||
12 General Purpose TSX1 / Touchscreen X-plate 1 0 - 2.30V No
|
||||
13 General Purpose TSX2 / Touchscreen X-plate 2 0 - 2.30V No
|
||||
14 General Purpose TSY1 / Touchscreen Y-plate 1 0 - 2.30V No
|
||||
15 General Purpose TSY2 / Touchscreen Y-plate 2 0 - 2.30V No
|
||||
|
|
@ -225,8 +225,6 @@ pwm[1-*]_auto_point[1-*]_temp_hyst
|
|||
to PWM output channels.
|
||||
RW
|
||||
|
||||
OR
|
||||
|
||||
temp[1-*]_auto_point[1-*]_pwm
|
||||
temp[1-*]_auto_point[1-*]_temp
|
||||
temp[1-*]_auto_point[1-*]_temp_hyst
|
||||
|
|
@ -235,6 +233,15 @@ temp[1-*]_auto_point[1-*]_temp_hyst
|
|||
to temperature channels.
|
||||
RW
|
||||
|
||||
There is a third case where trip points are associated to both PWM output
|
||||
channels and temperature channels: the PWM values are associated to PWM
|
||||
output channels while the temperature values are associated to temperature
|
||||
channels. In that case, the result is determined by the mapping between
|
||||
temperature inputs and PWM outputs. When several temperature inputs are
|
||||
mapped to a given PWM output, this leads to several candidate PWM values.
|
||||
The actual result is up to the chip, but in general the highest candidate
|
||||
value (fastest fan speed) wins.
|
||||
|
||||
|
||||
****************
|
||||
* Temperatures *
|
||||
|
|
|
|||
|
|
@ -32,8 +32,6 @@ Authors:
|
|||
Module Parameters
|
||||
-----------------
|
||||
|
||||
* force_addr: int
|
||||
Initialize the ISA address of the sensors
|
||||
* force_i2c: int
|
||||
Initialize the I2C address of the sensors
|
||||
* init: int
|
||||
|
|
@ -70,3 +68,30 @@ doesn't help, you may just ignore the bogus VID reading with no harm done.
|
|||
For further information on this driver see the w83781d driver documentation.
|
||||
|
||||
[1] http://www.lm-sensors.org/browser/lm-sensors/trunk/doc/vid
|
||||
|
||||
Forcing the address
|
||||
-------------------
|
||||
|
||||
The driver used to have a module parameter named force_addr, which could
|
||||
be used to force the base I/O address of the hardware monitoring block.
|
||||
This was meant as a workaround for mainboards with a broken BIOS. This
|
||||
module parameter is gone for technical reasons. If you need this feature,
|
||||
you can obtain the same result by using the isaset tool (part of
|
||||
lm-sensors) before loading the driver:
|
||||
|
||||
# Enter the Super I/O config space
|
||||
isaset -y -f 0x2e 0x87
|
||||
isaset -y -f 0x2e 0x87
|
||||
|
||||
# Select the hwmon logical device
|
||||
isaset -y 0x2e 0x2f 0x07 0x0b
|
||||
|
||||
# Set the base I/O address (to 0x290 in this example)
|
||||
isaset -y 0x2e 0x2f 0x60 0x02
|
||||
isaset -y 0x2e 0x2f 0x61 0x90
|
||||
|
||||
# Exit the Super-I/O config space
|
||||
isaset -y -f 0x2e 0xaa
|
||||
|
||||
The above sequence assumes a Super-I/O config space at 0x2e/0x2f, but
|
||||
0x4e/0x4f is also possible.
|
||||
|
|
|
|||
|
|
@ -1,62 +0,0 @@
|
|||
Kernel driver i2c-voodoo3
|
||||
|
||||
Supported adapters:
|
||||
* 3dfx Voodoo3 based cards
|
||||
* Voodoo Banshee based cards
|
||||
|
||||
Authors:
|
||||
Frodo Looijaard <frodol@dds.nl>,
|
||||
Philip Edelbrock <phil@netroedge.com>,
|
||||
Ralph Metzler <rjkm@thp.uni-koeln.de>,
|
||||
Mark D. Studebaker <mdsxyz123@yahoo.com>
|
||||
|
||||
Main contact: Philip Edelbrock <phil@netroedge.com>
|
||||
|
||||
The code is based upon Ralph's test code (he did the hard stuff ;')
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
The 3dfx Voodoo3 chip contains two I2C interfaces (aka a I2C 'master' or
|
||||
'host').
|
||||
|
||||
The first interface is used for DDC (Data Display Channel) which is a
|
||||
serial channel through the VGA monitor connector to a DDC-compliant
|
||||
monitor. This interface is defined by the Video Electronics Standards
|
||||
Association (VESA). The standards are available for purchase at
|
||||
http://www.vesa.org .
|
||||
|
||||
The second interface is a general-purpose I2C bus. The intent by 3dfx was
|
||||
to allow manufacturers to add extra chips to the video card such as a
|
||||
TV-out chip such as the BT869 or possibly even I2C based temperature
|
||||
sensors like the ADM1021 or LM75.
|
||||
|
||||
Stability
|
||||
---------
|
||||
|
||||
Seems to be stable on the test machine, but needs more testing on other
|
||||
machines. Simultaneous accesses of the DDC and I2C busses may cause errors.
|
||||
|
||||
Supported Devices
|
||||
-----------------
|
||||
|
||||
Specifically, this driver was written and tested on the '3dfx Voodoo3 AGP
|
||||
3000' which has a tv-out feature (s-video or composite). According to the
|
||||
docs and discussions, this code should work for any Voodoo3 based cards as
|
||||
well as Voodoo Banshee based cards. The DDC interface has been tested on a
|
||||
Voodoo Banshee card.
|
||||
|
||||
Issues
|
||||
------
|
||||
|
||||
Probably many, but it seems to work OK on my system. :')
|
||||
|
||||
|
||||
External Device Connection
|
||||
--------------------------
|
||||
|
||||
The digital video input jumpers give availability to the I2C bus.
|
||||
Specifically, pins 13 and 25 (bottom row middle, and bottom right-end) are
|
||||
the I2C clock and I2C data lines, respectively. +5V and GND are probably
|
||||
also easily available making the addition of extra I2C/SMBus devices easy
|
||||
to implement.
|
||||
|
|
@ -2,9 +2,9 @@ MODULE: i2c-stub
|
|||
|
||||
DESCRIPTION:
|
||||
|
||||
This module is a very simple fake I2C/SMBus driver. It implements four
|
||||
types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, and
|
||||
(r/w) word data.
|
||||
This module is a very simple fake I2C/SMBus driver. It implements five
|
||||
types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, (r/w)
|
||||
word data, and (r/w) I2C block data.
|
||||
|
||||
You need to provide chip addresses as a module parameter when loading this
|
||||
driver, which will then only react to SMBus commands to these addresses.
|
||||
|
|
@ -21,8 +21,8 @@ EEPROMs, among others.
|
|||
|
||||
The typical use-case is like this:
|
||||
1. load this module
|
||||
2. use i2cset (from lm_sensors project) to pre-load some data
|
||||
3. load the target sensors chip driver module
|
||||
2. use i2cset (from the i2c-tools project) to pre-load some data
|
||||
3. load the target chip driver module
|
||||
4. observe its behavior in the kernel log
|
||||
|
||||
There's a script named i2c-stub-from-dump in the i2c-tools package which
|
||||
|
|
@ -33,6 +33,12 @@ PARAMETERS:
|
|||
int chip_addr[10]:
|
||||
The SMBus addresses to emulate chips at.
|
||||
|
||||
unsigned long functionality:
|
||||
Functionality override, to disable some commands. See I2C_FUNC_*
|
||||
constants in <linux/i2c.h> for the suitable values. For example,
|
||||
value 0x1f0000 would only enable the quick, byte and byte data
|
||||
commands.
|
||||
|
||||
CAVEATS:
|
||||
|
||||
If your target driver polls some byte or word waiting for it to change, the
|
||||
|
|
|
|||
|
|
@ -0,0 +1,44 @@
|
|||
I2C device driver binding control from user-space
|
||||
=================================================
|
||||
|
||||
Up to kernel 2.6.32, many i2c drivers used helper macros provided by
|
||||
<linux/i2c.h> which created standard module parameters to let the user
|
||||
control how the driver would probe i2c buses and attach to devices. These
|
||||
parameters were known as "probe" (to let the driver probe for an extra
|
||||
address), "force" (to forcibly attach the driver to a given device) and
|
||||
"ignore" (to prevent a driver from probing a given address).
|
||||
|
||||
With the conversion of the i2c subsystem to the standard device driver
|
||||
binding model, it became clear that these per-module parameters were no
|
||||
longer needed, and that a centralized implementation was possible. The new,
|
||||
sysfs-based interface is described in the documentation file
|
||||
"instantiating-devices", section "Method 4: Instantiate from user-space".
|
||||
|
||||
Below is a mapping from the old module parameters to the new interface.
|
||||
|
||||
Attaching a driver to an I2C device
|
||||
-----------------------------------
|
||||
|
||||
Old method (module parameters):
|
||||
# modprobe <driver> probe=1,0x2d
|
||||
# modprobe <driver> force=1,0x2d
|
||||
# modprobe <driver> force_<device>=1,0x2d
|
||||
|
||||
New method (sysfs interface):
|
||||
# echo <device> 0x2d > /sys/bus/i2c/devices/i2c-1/new_device
|
||||
|
||||
Preventing a driver from attaching to an I2C device
|
||||
---------------------------------------------------
|
||||
|
||||
Old method (module parameters):
|
||||
# modprobe <driver> ignore=1,0x2f
|
||||
|
||||
New method (sysfs interface):
|
||||
# echo dummy 0x2f > /sys/bus/i2c/devices/i2c-1/new_device
|
||||
# modprobe <driver>
|
||||
|
||||
Of course, it is important to instantiate the "dummy" device before loading
|
||||
the driver. The dummy device will be handled by i2c-core itself, preventing
|
||||
other drivers from binding to it later on. If there is a real device at the
|
||||
problematic address, and you want another driver to bind to it, then simply
|
||||
pass the name of the device in question instead of "dummy".
|
||||
|
|
@ -5,7 +5,7 @@ GigaSet 307x Device Driver
|
|||
------------
|
||||
1.1. Hardware
|
||||
--------
|
||||
This release supports the connection of the Gigaset 307x/417x family of
|
||||
This driver supports the connection of the Gigaset 307x/417x family of
|
||||
ISDN DECT bases via Gigaset M101 Data, Gigaset M105 Data or direct USB
|
||||
connection. The following devices are reported to be compatible:
|
||||
|
||||
|
|
@ -33,7 +33,7 @@ GigaSet 307x Device Driver
|
|||
http://gigaset307x.sourceforge.net/
|
||||
|
||||
We had also reports from users of Gigaset M105 who could use the drivers
|
||||
with SX 100 and CX 100 ISDN bases (only in unimodem mode, see section 2.4.)
|
||||
with SX 100 and CX 100 ISDN bases (only in unimodem mode, see section 2.5.)
|
||||
If you have another device that works with our driver, please let us know.
|
||||
|
||||
Chances of getting an USB device to work are good if the output of
|
||||
|
|
@ -49,7 +49,7 @@ GigaSet 307x Device Driver
|
|||
--------
|
||||
The driver works with ISDN4linux and so can be used with any software
|
||||
which is able to use ISDN4linux for ISDN connections (voice or data).
|
||||
CAPI4Linux support is planned but not yet available.
|
||||
Experimental Kernel CAPI support is available as a compilation option.
|
||||
|
||||
There are some user space tools available at
|
||||
http://sourceforge.net/projects/gigaset307x/
|
||||
|
|
@ -102,20 +102,28 @@ GigaSet 307x Device Driver
|
|||
2.3. ISDN4linux
|
||||
----------
|
||||
This is the "normal" mode of operation. After loading the module you can
|
||||
set up the ISDN system just as you'd do with any ISDN card.
|
||||
Your distribution should provide some configuration utility.
|
||||
If not, you can use some HOWTOs like
|
||||
set up the ISDN system just as you'd do with any ISDN card supported by
|
||||
the ISDN4Linux subsystem. Most distributions provide some configuration
|
||||
utility. If not, you can use some HOWTOs like
|
||||
http://www.linuxhaven.de/dlhp/HOWTO/DE-ISDN-HOWTO-5.html
|
||||
If this doesn't work, because you have some recent device like SX100 where
|
||||
If this doesn't work, because you have some device like SX100 where
|
||||
debug output (see section 3.2.) shows something like this when dialing
|
||||
CMD Received: ERROR
|
||||
Available Params: 0
|
||||
Connection State: 0, Response: -1
|
||||
gigaset_process_response: resp_code -1 in ConState 0 !
|
||||
Timeout occurred
|
||||
you might need to use unimodem mode:
|
||||
you might need to use unimodem mode. (see section 2.5.)
|
||||
|
||||
2.4. Unimodem mode
|
||||
2.4. CAPI
|
||||
----
|
||||
If the driver is compiled with CAPI support (kernel configuration option
|
||||
GIGASET_CAPI, experimental) it can also be used with CAPI 2.0 kernel and
|
||||
user space applications. ISDN4Linux is supported in this configuration
|
||||
via the capidrv compatibility driver. The kernel module capidrv.ko must
|
||||
be loaded explicitly ("modprobe capidrv") if needed.
|
||||
|
||||
2.5. Unimodem mode
|
||||
-------------
|
||||
This is needed for some devices [e.g. SX100] as they have problems with
|
||||
the "normal" commands.
|
||||
|
|
@ -160,7 +168,7 @@ GigaSet 307x Device Driver
|
|||
configuration file like /etc/modprobe.conf.local,
|
||||
using that should be preferred.
|
||||
|
||||
2.5. Call-ID (CID) mode
|
||||
2.6. Call-ID (CID) mode
|
||||
------------------
|
||||
Call-IDs are numbers used to tag commands to, and responses from, the
|
||||
Gigaset base in order to support the simultaneous handling of multiple
|
||||
|
|
@ -188,7 +196,7 @@ GigaSet 307x Device Driver
|
|||
You can also use /sys/class/tty/ttyGxy/cidmode for changing the CID mode
|
||||
setting (ttyGxy is ttyGU0 or ttyGB0).
|
||||
|
||||
2.6. Unregistered Wireless Devices (M101/M105)
|
||||
2.7. Unregistered Wireless Devices (M101/M105)
|
||||
-----------------------------------------
|
||||
The main purpose of the ser_gigaset and usb_gigaset drivers is to allow
|
||||
the M101 and M105 wireless devices to be used as ISDN devices for ISDN
|
||||
|
|
@ -228,7 +236,7 @@ GigaSet 307x Device Driver
|
|||
You have two or more DECT data adapters (M101/M105) and only the
|
||||
first one you turn on works.
|
||||
Solution:
|
||||
Select Unimodem mode for all DECT data adapters. (see section 2.4.)
|
||||
Select Unimodem mode for all DECT data adapters. (see section 2.5.)
|
||||
|
||||
Problem:
|
||||
Messages like this:
|
||||
|
|
@ -236,7 +244,7 @@ GigaSet 307x Device Driver
|
|||
appear in your syslog.
|
||||
Solution:
|
||||
Check whether your M10x wireless device is correctly registered to the
|
||||
Gigaset base. (see section 2.6.)
|
||||
Gigaset base. (see section 2.7.)
|
||||
|
||||
3.2. Telling the driver to provide more information
|
||||
----------------------------------------------
|
||||
|
|
|
|||
|
|
@ -85,7 +85,6 @@ parameter is applicable:
|
|||
PPT Parallel port support is enabled.
|
||||
PS2 Appropriate PS/2 support is enabled.
|
||||
RAM RAM disk support is enabled.
|
||||
ROOTPLUG The example Root Plug LSM is enabled.
|
||||
S390 S390 architecture is enabled.
|
||||
SCSI Appropriate SCSI support is enabled.
|
||||
A lot of drivers has their options described inside of
|
||||
|
|
@ -345,6 +344,15 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
Change the amount of debugging information output
|
||||
when initialising the APIC and IO-APIC components.
|
||||
|
||||
show_lapic= [APIC,X86] Advanced Programmable Interrupt Controller
|
||||
Limit apic dumping. The parameter defines the maximal
|
||||
number of local apics being dumped. Also it is possible
|
||||
to set it to "all" by meaning -- no limit here.
|
||||
Format: { 1 (default) | 2 | ... | all }.
|
||||
The parameter valid if only apic=debug or
|
||||
apic=verbose is specified.
|
||||
Example: apic=debug show_lapic=all
|
||||
|
||||
apm= [APM] Advanced Power Management
|
||||
See header of arch/x86/kernel/apm_32.c.
|
||||
|
||||
|
|
@ -779,6 +787,13 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
by the set_ftrace_notrace file in the debugfs
|
||||
tracing directory.
|
||||
|
||||
ftrace_graph_filter=[function-list]
|
||||
[FTRACE] Limit the top level callers functions traced
|
||||
by the function graph tracer at boot up.
|
||||
function-list is a comma separated list of functions
|
||||
that can be changed at run time by the
|
||||
set_graph_function file in the debugfs tracing directory.
|
||||
|
||||
gamecon.map[2|3]=
|
||||
[HW,JOY] Multisystem joystick and NES/SNES/PSX pad
|
||||
support via parallel port (up to 5 devices per port)
|
||||
|
|
@ -2032,8 +2047,15 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
|
||||
print-fatal-signals=
|
||||
[KNL] debug: print fatal signals
|
||||
print-fatal-signals=1: print segfault info to
|
||||
the kernel console.
|
||||
|
||||
If enabled, warn about various signal handling
|
||||
related application anomalies: too many signals,
|
||||
too many POSIX.1 timers, fatal signals causing a
|
||||
coredump - etc.
|
||||
|
||||
If you hit the warning due to signal overflow,
|
||||
you might want to try "ulimit -i unlimited".
|
||||
|
||||
default: off.
|
||||
|
||||
printk.time= Show timing data prefixed to each printk message line
|
||||
|
|
@ -2164,15 +2186,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
Useful for devices that are detected asynchronously
|
||||
(e.g. USB and MMC devices).
|
||||
|
||||
root_plug.vendor_id=
|
||||
[ROOTPLUG] Override the default vendor ID
|
||||
|
||||
root_plug.product_id=
|
||||
[ROOTPLUG] Override the default product ID
|
||||
|
||||
root_plug.debug=
|
||||
[ROOTPLUG] Enable debugging output
|
||||
|
||||
rw [KNL] Mount root device read-write on boot
|
||||
|
||||
S [KNL] Run init in single mode
|
||||
|
|
@ -2182,6 +2195,8 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
|
||||
sbni= [NET] Granch SBNI12 leased line adapter
|
||||
|
||||
sched_debug [KNL] Enables verbose scheduler debug messages.
|
||||
|
||||
sc1200wdt= [HW,WDT] SC1200 WDT (watchdog) driver
|
||||
Format: <io>[,<timeout>[,<isapnp>]]
|
||||
|
||||
|
|
@ -2590,6 +2605,9 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
uart6850= [HW,OSS]
|
||||
Format: <io>,<irq>
|
||||
|
||||
uhash_entries= [KNL,NET]
|
||||
Set number of hash buckets for UDP/UDP-Lite connections
|
||||
|
||||
uhci-hcd.ignore_oc=
|
||||
[USB] Ignore overcurrent events (default N).
|
||||
Some badly-designed motherboards generate lots of
|
||||
|
|
@ -2729,6 +2747,15 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
Default is 1, i.e. UTF-8 mode is enabled for all
|
||||
newly opened terminals.
|
||||
|
||||
vt.global_cursor_default=
|
||||
[VT]
|
||||
Format=<-1|0|1>
|
||||
Set system-wide default for whether a cursor
|
||||
is shown on new VTs. Default is -1,
|
||||
i.e. cursors will be created by default unless
|
||||
overridden by individual drivers. 0 will hide
|
||||
cursors, 1 will display them.
|
||||
|
||||
waveartist= [HW,OSS]
|
||||
Format: <io>,<irq>,<dma>,<dma2>
|
||||
|
||||
|
|
|
|||
|
|
@ -593,6 +593,115 @@ struct kvm_irqchip {
|
|||
} chip;
|
||||
};
|
||||
|
||||
4.27 KVM_XEN_HVM_CONFIG
|
||||
|
||||
Capability: KVM_CAP_XEN_HVM
|
||||
Architectures: x86
|
||||
Type: vm ioctl
|
||||
Parameters: struct kvm_xen_hvm_config (in)
|
||||
Returns: 0 on success, -1 on error
|
||||
|
||||
Sets the MSR that the Xen HVM guest uses to initialize its hypercall
|
||||
page, and provides the starting address and size of the hypercall
|
||||
blobs in userspace. When the guest writes the MSR, kvm copies one
|
||||
page of a blob (32- or 64-bit, depending on the vcpu mode) to guest
|
||||
memory.
|
||||
|
||||
struct kvm_xen_hvm_config {
|
||||
__u32 flags;
|
||||
__u32 msr;
|
||||
__u64 blob_addr_32;
|
||||
__u64 blob_addr_64;
|
||||
__u8 blob_size_32;
|
||||
__u8 blob_size_64;
|
||||
__u8 pad2[30];
|
||||
};
|
||||
|
||||
4.27 KVM_GET_CLOCK
|
||||
|
||||
Capability: KVM_CAP_ADJUST_CLOCK
|
||||
Architectures: x86
|
||||
Type: vm ioctl
|
||||
Parameters: struct kvm_clock_data (out)
|
||||
Returns: 0 on success, -1 on error
|
||||
|
||||
Gets the current timestamp of kvmclock as seen by the current guest. In
|
||||
conjunction with KVM_SET_CLOCK, it is used to ensure monotonicity on scenarios
|
||||
such as migration.
|
||||
|
||||
struct kvm_clock_data {
|
||||
__u64 clock; /* kvmclock current value */
|
||||
__u32 flags;
|
||||
__u32 pad[9];
|
||||
};
|
||||
|
||||
4.28 KVM_SET_CLOCK
|
||||
|
||||
Capability: KVM_CAP_ADJUST_CLOCK
|
||||
Architectures: x86
|
||||
Type: vm ioctl
|
||||
Parameters: struct kvm_clock_data (in)
|
||||
Returns: 0 on success, -1 on error
|
||||
|
||||
Sets the current timestamp of kvmclock to the valued specific in its parameter.
|
||||
In conjunction with KVM_GET_CLOCK, it is used to ensure monotonicity on scenarios
|
||||
such as migration.
|
||||
|
||||
struct kvm_clock_data {
|
||||
__u64 clock; /* kvmclock current value */
|
||||
__u32 flags;
|
||||
__u32 pad[9];
|
||||
};
|
||||
|
||||
4.29 KVM_GET_VCPU_EVENTS
|
||||
|
||||
Capability: KVM_CAP_VCPU_EVENTS
|
||||
Architectures: x86
|
||||
Type: vm ioctl
|
||||
Parameters: struct kvm_vcpu_event (out)
|
||||
Returns: 0 on success, -1 on error
|
||||
|
||||
Gets currently pending exceptions, interrupts, and NMIs as well as related
|
||||
states of the vcpu.
|
||||
|
||||
struct kvm_vcpu_events {
|
||||
struct {
|
||||
__u8 injected;
|
||||
__u8 nr;
|
||||
__u8 has_error_code;
|
||||
__u8 pad;
|
||||
__u32 error_code;
|
||||
} exception;
|
||||
struct {
|
||||
__u8 injected;
|
||||
__u8 nr;
|
||||
__u8 soft;
|
||||
__u8 pad;
|
||||
} interrupt;
|
||||
struct {
|
||||
__u8 injected;
|
||||
__u8 pending;
|
||||
__u8 masked;
|
||||
__u8 pad;
|
||||
} nmi;
|
||||
__u32 sipi_vector;
|
||||
__u32 flags; /* must be zero */
|
||||
};
|
||||
|
||||
4.30 KVM_SET_VCPU_EVENTS
|
||||
|
||||
Capability: KVM_CAP_VCPU_EVENTS
|
||||
Architectures: x86
|
||||
Type: vm ioctl
|
||||
Parameters: struct kvm_vcpu_event (in)
|
||||
Returns: 0 on success, -1 on error
|
||||
|
||||
Set pending exceptions, interrupts, and NMIs as well as related states of the
|
||||
vcpu.
|
||||
|
||||
See KVM_GET_VCPU_EVENTS for the data structure.
|
||||
|
||||
|
||||
5. The kvm_run structure
|
||||
|
||||
Application code obtains a pointer to the kvm_run structure by
|
||||
|
|
|
|||
|
|
@ -304,7 +304,7 @@ static void *map_zeroed_pages(unsigned int num)
|
|||
addr = mmap(NULL, getpagesize() * num,
|
||||
PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, fd, 0);
|
||||
if (addr == MAP_FAILED)
|
||||
err(1, "Mmaping %u pages of /dev/zero", num);
|
||||
err(1, "Mmapping %u pages of /dev/zero", num);
|
||||
|
||||
/*
|
||||
* One neat mmap feature is that you can close the fd, and it
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
|
||||
Linux Ethernet Bonding Driver HOWTO
|
||||
|
||||
Latest update: 12 November 2007
|
||||
Latest update: 23 September 2009
|
||||
|
||||
Initial release : Thomas Davis <tadavis at lbl.gov>
|
||||
Corrections, HA extensions : 2000/10/03-15 :
|
||||
|
|
@ -614,6 +614,46 @@ primary
|
|||
|
||||
The primary option is only valid for active-backup mode.
|
||||
|
||||
primary_reselect
|
||||
|
||||
Specifies the reselection policy for the primary slave. This
|
||||
affects how the primary slave is chosen to become the active slave
|
||||
when failure of the active slave or recovery of the primary slave
|
||||
occurs. This option is designed to prevent flip-flopping between
|
||||
the primary slave and other slaves. Possible values are:
|
||||
|
||||
always or 0 (default)
|
||||
|
||||
The primary slave becomes the active slave whenever it
|
||||
comes back up.
|
||||
|
||||
better or 1
|
||||
|
||||
The primary slave becomes the active slave when it comes
|
||||
back up, if the speed and duplex of the primary slave is
|
||||
better than the speed and duplex of the current active
|
||||
slave.
|
||||
|
||||
failure or 2
|
||||
|
||||
The primary slave becomes the active slave only if the
|
||||
current active slave fails and the primary slave is up.
|
||||
|
||||
The primary_reselect setting is ignored in two cases:
|
||||
|
||||
If no slaves are active, the first slave to recover is
|
||||
made the active slave.
|
||||
|
||||
When initially enslaved, the primary slave is always made
|
||||
the active slave.
|
||||
|
||||
Changing the primary_reselect policy via sysfs will cause an
|
||||
immediate selection of the best active slave according to the new
|
||||
policy. This may or may not result in a change of the active
|
||||
slave, depending upon the circumstances.
|
||||
|
||||
This option was added for bonding version 3.6.0.
|
||||
|
||||
updelay
|
||||
|
||||
Specifies the time, in milliseconds, to wait before enabling a
|
||||
|
|
|
|||
|
|
@ -164,6 +164,14 @@ tcp_congestion_control - STRING
|
|||
additional choices may be available based on kernel configuration.
|
||||
Default is set as part of kernel configuration.
|
||||
|
||||
tcp_cookie_size - INTEGER
|
||||
Default size of TCP Cookie Transactions (TCPCT) option, that may be
|
||||
overridden on a per socket basis by the TCPCT socket option.
|
||||
Values greater than the maximum (16) are interpreted as the maximum.
|
||||
Values greater than zero and less than the minimum (8) are interpreted
|
||||
as the minimum. Odd values are interpreted as the next even value.
|
||||
Default: 0 (off).
|
||||
|
||||
tcp_dsack - BOOLEAN
|
||||
Allows TCP to send "duplicate" SACKs.
|
||||
|
||||
|
|
@ -723,6 +731,12 @@ accept_source_route - BOOLEAN
|
|||
default TRUE (router)
|
||||
FALSE (host)
|
||||
|
||||
accept_local - BOOLEAN
|
||||
Accept packets with local source addresses. In combination with
|
||||
suitable routing, this can be used to direct packets between two
|
||||
local interfaces over the wire and have them accepted properly.
|
||||
default FALSE
|
||||
|
||||
rp_filter - INTEGER
|
||||
0 - No source validation.
|
||||
1 - Strict mode as defined in RFC3704 Strict Reverse Path
|
||||
|
|
@ -738,8 +752,8 @@ rp_filter - INTEGER
|
|||
to prevent IP spoofing from DDos attacks. If using asymmetric routing
|
||||
or other complicated routing, then loose mode is recommended.
|
||||
|
||||
conf/all/rp_filter must also be set to non-zero to do source validation
|
||||
on the interface
|
||||
The max value from conf/{all,interface}/rp_filter is used
|
||||
when doing source validation on the {interface}.
|
||||
|
||||
Default value is 0. Note that some distributions enable it
|
||||
in startup scripts.
|
||||
|
|
@ -1086,6 +1100,24 @@ accept_dad - INTEGER
|
|||
2: Enable DAD, and disable IPv6 operation if MAC-based duplicate
|
||||
link-local address has been found.
|
||||
|
||||
force_tllao - BOOLEAN
|
||||
Enable sending the target link-layer address option even when
|
||||
responding to a unicast neighbor solicitation.
|
||||
Default: FALSE
|
||||
|
||||
Quoting from RFC 2461, section 4.4, Target link-layer address:
|
||||
|
||||
"The option MUST be included for multicast solicitations in order to
|
||||
avoid infinite Neighbor Solicitation "recursion" when the peer node
|
||||
does not have a cache entry to return a Neighbor Advertisements
|
||||
message. When responding to unicast solicitations, the option can be
|
||||
omitted since the sender of the solicitation has the correct link-
|
||||
layer address; otherwise it would not have be able to send the unicast
|
||||
solicitation in the first place. However, including the link-layer
|
||||
address in this case adds little overhead and eliminates a potential
|
||||
race condition where the sender deletes the cached link-layer address
|
||||
prior to receiving a response to a previous solicitation."
|
||||
|
||||
icmp/*:
|
||||
ratelimit - INTEGER
|
||||
Limit the maximal rates for sending ICMPv6 packets.
|
||||
|
|
|
|||
|
|
@ -257,6 +257,8 @@ characters, each representing a particular tainted value.
|
|||
|
||||
10: 'W' if a warning has previously been issued by the kernel.
|
||||
|
||||
11: 'C' if a staging driver has been loaded.
|
||||
|
||||
The primary reason for the 'Tainted: ' string is to tell kernel
|
||||
debuggers if this is a clean kernel or if anything unusual has
|
||||
occurred. Tainting is permanent: even if an offending module is
|
||||
|
|
|
|||
|
|
@ -1,5 +1,17 @@
|
|||
This file details changes in 2.6 which affect PCMCIA card driver authors:
|
||||
|
||||
* no cs_error / CS_CHECK / CONFIG_PCMCIA_DEBUG (as of 2.6.33)
|
||||
Instead of the cs_error() callback or the CS_CHECK() macro, please use
|
||||
Linux-style checking of return values, and -- if necessary -- debug
|
||||
messages using "dev_dbg()" or "pr_debug()".
|
||||
|
||||
* New CIS tuple access (as of 2.6.33)
|
||||
Instead of pcmcia_get_{first,next}_tuple(), pcmcia_get_tuple_data() and
|
||||
pcmcia_parse_tuple(), a driver shall use "pcmcia_get_tuple()" if it is
|
||||
only interested in one (raw) tuple, or "pcmcia_loop_tuple()" if it is
|
||||
interested in all tuples of one type. To decode the MAC from CISTPL_FUNCE,
|
||||
a new helper "pcmcia_get_mac_from_cis()" was added.
|
||||
|
||||
* New configuration loop helper (as of 2.6.28)
|
||||
By calling pcmcia_loop_config(), a driver can iterate over all available
|
||||
configuration options. During a driver's probe() phase, one doesn't need
|
||||
|
|
|
|||
|
|
@ -104,7 +104,7 @@ to set the limit to 500mA when supplying power.
|
|||
|
||||
Consumers can control their supply current limit by calling :-
|
||||
|
||||
int regulator_set_current_limit(regulator, min_uV, max_uV);
|
||||
int regulator_set_current_limit(regulator, min_uA, max_uA);
|
||||
|
||||
Where min_uA and max_uA are the minimum and maximum acceptable current limit in
|
||||
microamps.
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ struct dev_pm_ops {
|
|||
...
|
||||
int (*runtime_suspend)(struct device *dev);
|
||||
int (*runtime_resume)(struct device *dev);
|
||||
void (*runtime_idle)(struct device *dev);
|
||||
int (*runtime_idle)(struct device *dev);
|
||||
...
|
||||
};
|
||||
|
||||
|
|
@ -71,9 +71,9 @@ what to do to handle the device).
|
|||
purpose).
|
||||
|
||||
In particular, if the driver requires remote wakeup capability for proper
|
||||
functioning and device_may_wakeup() returns 'false' for the device, then
|
||||
functioning and device_run_wake() returns 'false' for the device, then
|
||||
->runtime_suspend() should return -EBUSY. On the other hand, if
|
||||
device_may_wakeup() returns 'true' for the device and the device is put
|
||||
device_run_wake() returns 'true' for the device and the device is put
|
||||
into a low power state during the execution of its bus type's
|
||||
->runtime_suspend(), it is expected that remote wake-up (i.e. hardware mechanism
|
||||
allowing the device to request a change of its power state, such as PCI PME)
|
||||
|
|
@ -114,7 +114,8 @@ The action performed by a bus type's ->runtime_idle() callback is totally
|
|||
dependent on the bus type in question, but the expected and recommended action
|
||||
is to check if the device can be suspended (i.e. if all of the conditions
|
||||
necessary for suspending the device are satisfied) and to queue up a suspend
|
||||
request for the device in that case.
|
||||
request for the device in that case. The value returned by this callback is
|
||||
ignored by the PM core.
|
||||
|
||||
The helper functions provided by the PM core, described in Section 4, guarantee
|
||||
that the following constraints are met with respect to the bus type's run-time
|
||||
|
|
@ -214,6 +215,9 @@ defined in include/linux/pm.h:
|
|||
being executed for that device and it is not practical to wait for the
|
||||
suspend to complete; means "start a resume as soon as you've suspended"
|
||||
|
||||
unsigned int run_wake;
|
||||
- set if the device is capable of generating run-time wake-up events
|
||||
|
||||
enum rpm_status runtime_status;
|
||||
- the run-time PM status of the device; this field's initial value is
|
||||
RPM_SUSPENDED, which means that each device is initially regarded by the
|
||||
|
|
|
|||
|
|
@ -178,3 +178,13 @@ External interrupts:
|
|||
external irq3: interrupts = <1 3 n>;
|
||||
'n' is sense (0: level high, 1: edge rising, 2: edge falling 3: level low)
|
||||
|
||||
fsl,mpc5200-mscan nodes
|
||||
-----------------------
|
||||
In addition to the required compatible-, reg- and interrupt-properites, you can
|
||||
also specify which clock source shall be used for the controller:
|
||||
|
||||
- fsl,mscan-clock-source- a string describing the clock source. Valid values
|
||||
are: "ip" for ip bus clock
|
||||
"ref" for reference clock (XTAL)
|
||||
"ref" is default in case this property is not
|
||||
present.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,65 @@
|
|||
1 Release Date : Tues. July 28, 2009 10:12:45 PST 2009 -
|
||||
(emaild-id:megaraidlinux@lsi.com)
|
||||
Bo Yang
|
||||
|
||||
2 Current Version : 00.00.04.12
|
||||
3 Older Version : 00.00.04.10
|
||||
|
||||
1. Change the AEN sys PD update from scsi_scan to
|
||||
scsi_add_device and scsi_remove_device.
|
||||
2. Takeoff the debug print-out in aen_polling routine.
|
||||
|
||||
1 Release Date : Thur. July 02, 2009 10:12:45 PST 2009 -
|
||||
(emaild-id:megaraidlinux@lsi.com)
|
||||
Bo Yang
|
||||
|
||||
2 Current Version : 00.00.04.10
|
||||
3 Older Version : 00.00.04.08
|
||||
|
||||
1. Add the 3 mins timeout during the controller initialize.
|
||||
2. Add the fix for 64bit sense date errors.
|
||||
|
||||
1 Release Date : Tues. May 05, 2009 10:12:45 PST 2009 -
|
||||
(emaild-id:megaraidlinux@lsi.com)
|
||||
Bo Yang
|
||||
|
||||
2 Current Version : 00.00.04.08
|
||||
3 Older Version : 00.00.04.06
|
||||
|
||||
1. Add the fix of pending in FW after deleted the logic drives.
|
||||
2. Add the fix of deallocating memory after get pdlist.
|
||||
|
||||
1 Release Date : Tues. March 26, 2009 10:12:45 PST 2009 -
|
||||
(emaild-id:megaraidlinux@lsi.com)
|
||||
Bo Yang
|
||||
|
||||
2 Current Version : 00.00.04.06
|
||||
3 Older Version : 00.00.04.04
|
||||
|
||||
1. Add the fix of the driver cmd empty fix of the driver cmd empty.
|
||||
2. Add the fix of the driver MSM AEN CMD cause the system slow.
|
||||
|
||||
1 Release Date : Tues. March 03, 2009 10:12:45 PST 2009 -
|
||||
(emaild-id:megaraidlinux@lsi.com)
|
||||
Bo Yang
|
||||
|
||||
2 Current Version : 00.00.04.04
|
||||
3 Older Version : 00.00.04.01
|
||||
|
||||
1. Add the Tape drive fix to the driver: If the command is for
|
||||
the tape device, set the pthru timeout to the os layer timeout value.
|
||||
|
||||
2. Add Poll_wait mechanism to Gen-2 Linux driv.
|
||||
In the aen handler, driver needs to wakeup poll handler similar to
|
||||
the way it raises SIGIO.
|
||||
|
||||
3. Add new controller new SAS2 support to the driver.
|
||||
|
||||
4. Report the unconfigured PD (system PD) to OS.
|
||||
|
||||
5. Add the IEEE SGL support to the driver
|
||||
|
||||
6. Reasign the Application cmds to SAS2 controller
|
||||
|
||||
1 Release Date : Thur.July. 24 11:41:51 PST 2008 -
|
||||
(emaild-id:megaraidlinux@lsi.com)
|
||||
|
|
@ -185,7 +247,7 @@ ii. FW enables WCE bit in Mode Sense cmd for drives that are configured
|
|||
Disks are exposed with WCE=1. User is advised to enable Write Back
|
||||
mode only when the controller has battery backup. At this time
|
||||
Synhronize cache is not supported by the FW. Driver will short-cycle
|
||||
the cmd and return sucess without sending down to FW.
|
||||
the cmd and return success without sending down to FW.
|
||||
|
||||
1 Release Date : Sun Jan. 14 11:21:32 PDT 2007 -
|
||||
Sumant Patro <Sumant.Patro@lsil.com>/Bo Yang
|
||||
|
|
|
|||
|
|
@ -41,6 +41,13 @@ expand files, provided the time taken to do so isn't too long.
|
|||
Operations of both types may sleep during execution, thus tying up the thread
|
||||
loaned to it.
|
||||
|
||||
A further class of work item is available, based on the slow work item class:
|
||||
|
||||
(*) Delayed slow work items.
|
||||
|
||||
These are slow work items that have a timer to defer queueing of the item for
|
||||
a while.
|
||||
|
||||
|
||||
THREAD-TO-CLASS ALLOCATION
|
||||
--------------------------
|
||||
|
|
@ -64,9 +71,11 @@ USING SLOW WORK ITEMS
|
|||
Firstly, a module or subsystem wanting to make use of slow work items must
|
||||
register its interest:
|
||||
|
||||
int ret = slow_work_register_user();
|
||||
int ret = slow_work_register_user(struct module *module);
|
||||
|
||||
This will return 0 if successful, or a -ve error upon failure.
|
||||
This will return 0 if successful, or a -ve error upon failure. The module
|
||||
pointer should be the module interested in using this facility (almost
|
||||
certainly THIS_MODULE).
|
||||
|
||||
|
||||
Slow work items may then be set up by:
|
||||
|
|
@ -91,6 +100,10 @@ Slow work items may then be set up by:
|
|||
|
||||
slow_work_init(&myitem, &myitem_ops);
|
||||
|
||||
or:
|
||||
|
||||
delayed_slow_work_init(&myitem, &myitem_ops);
|
||||
|
||||
or:
|
||||
|
||||
vslow_work_init(&myitem, &myitem_ops);
|
||||
|
|
@ -102,15 +115,92 @@ A suitably set up work item can then be enqueued for processing:
|
|||
int ret = slow_work_enqueue(&myitem);
|
||||
|
||||
This will return a -ve error if the thread pool is unable to gain a reference
|
||||
on the item, 0 otherwise.
|
||||
on the item, 0 otherwise, or (for delayed work):
|
||||
|
||||
int ret = delayed_slow_work_enqueue(&myitem, my_jiffy_delay);
|
||||
|
||||
|
||||
The items are reference counted, so there ought to be no need for a flush
|
||||
operation. When all a module's slow work items have been processed, and the
|
||||
operation. But as the reference counting is optional, means to cancel
|
||||
existing work items are also included:
|
||||
|
||||
cancel_slow_work(&myitem);
|
||||
cancel_delayed_slow_work(&myitem);
|
||||
|
||||
can be used to cancel pending work. The above cancel function waits for
|
||||
existing work to have been executed (or prevent execution of them, depending
|
||||
on timing).
|
||||
|
||||
|
||||
When all a module's slow work items have been processed, and the
|
||||
module has no further interest in the facility, it should unregister its
|
||||
interest:
|
||||
|
||||
slow_work_unregister_user();
|
||||
slow_work_unregister_user(struct module *module);
|
||||
|
||||
The module pointer is used to wait for all outstanding work items for that
|
||||
module before completing the unregistration. This prevents the put_ref() code
|
||||
from being taken away before it completes. module should almost certainly be
|
||||
THIS_MODULE.
|
||||
|
||||
|
||||
================
|
||||
HELPER FUNCTIONS
|
||||
================
|
||||
|
||||
The slow-work facility provides a function by which it can be determined
|
||||
whether or not an item is queued for later execution:
|
||||
|
||||
bool queued = slow_work_is_queued(struct slow_work *work);
|
||||
|
||||
If it returns false, then the item is not on the queue (it may be executing
|
||||
with a requeue pending). This can be used to work out whether an item on which
|
||||
another depends is on the queue, thus allowing a dependent item to be queued
|
||||
after it.
|
||||
|
||||
If the above shows an item on which another depends not to be queued, then the
|
||||
owner of the dependent item might need to wait. However, to avoid locking up
|
||||
the threads unnecessarily be sleeping in them, it can make sense under some
|
||||
circumstances to return the work item to the queue, thus deferring it until
|
||||
some other items have had a chance to make use of the yielded thread.
|
||||
|
||||
To yield a thread and defer an item, the work function should simply enqueue
|
||||
the work item again and return. However, this doesn't work if there's nothing
|
||||
actually on the queue, as the thread just vacated will jump straight back into
|
||||
the item's work function, thus busy waiting on a CPU.
|
||||
|
||||
Instead, the item should use the thread to wait for the dependency to go away,
|
||||
but rather than using schedule() or schedule_timeout() to sleep, it should use
|
||||
the following function:
|
||||
|
||||
bool requeue = slow_work_sleep_till_thread_needed(
|
||||
struct slow_work *work,
|
||||
signed long *_timeout);
|
||||
|
||||
This will add a second wait and then sleep, such that it will be woken up if
|
||||
either something appears on the queue that could usefully make use of the
|
||||
thread - and behind which this item can be queued, or if the event the caller
|
||||
set up to wait for happens. True will be returned if something else appeared
|
||||
on the queue and this work function should perhaps return, of false if
|
||||
something else woke it up. The timeout is as for schedule_timeout().
|
||||
|
||||
For example:
|
||||
|
||||
wq = bit_waitqueue(&my_flags, MY_BIT);
|
||||
init_wait(&wait);
|
||||
requeue = false;
|
||||
do {
|
||||
prepare_to_wait(wq, &wait, TASK_UNINTERRUPTIBLE);
|
||||
if (!test_bit(MY_BIT, &my_flags))
|
||||
break;
|
||||
requeue = slow_work_sleep_till_thread_needed(&my_work,
|
||||
&timeout);
|
||||
} while (timeout > 0 && !requeue);
|
||||
finish_wait(wq, &wait);
|
||||
if (!test_bit(MY_BIT, &my_flags)
|
||||
goto do_my_thing;
|
||||
if (requeue)
|
||||
return; // to slow_work
|
||||
|
||||
|
||||
===============
|
||||
|
|
@ -118,7 +208,8 @@ ITEM OPERATIONS
|
|||
===============
|
||||
|
||||
Each work item requires a table of operations of type struct slow_work_ops.
|
||||
All members are required:
|
||||
Only ->execute() is required; the getting and putting of a reference and the
|
||||
describing of an item are all optional.
|
||||
|
||||
(*) Get a reference on an item:
|
||||
|
||||
|
|
@ -148,6 +239,16 @@ All members are required:
|
|||
This should perform the work required of the item. It may sleep, it may
|
||||
perform disk I/O and it may wait for locks.
|
||||
|
||||
(*) View an item through /proc:
|
||||
|
||||
void (*desc)(struct slow_work *work, struct seq_file *m);
|
||||
|
||||
If supplied, this should print to 'm' a small string describing the work
|
||||
the item is to do. This should be no more than about 40 characters, and
|
||||
shouldn't include a newline character.
|
||||
|
||||
See the 'Viewing executing and queued items' section below.
|
||||
|
||||
|
||||
==================
|
||||
POOL CONFIGURATION
|
||||
|
|
@ -172,3 +273,50 @@ The slow-work thread pool has a number of configurables:
|
|||
is bounded to between 1 and one fewer than the number of active threads.
|
||||
This ensures there is always at least one thread that can process very
|
||||
slow work items, and always at least one thread that won't.
|
||||
|
||||
|
||||
==================================
|
||||
VIEWING EXECUTING AND QUEUED ITEMS
|
||||
==================================
|
||||
|
||||
If CONFIG_SLOW_WORK_DEBUG is enabled, a debugfs file is made available:
|
||||
|
||||
/sys/kernel/debug/slow_work/runqueue
|
||||
|
||||
through which the list of work items being executed and the queues of items to
|
||||
be executed may be viewed. The owner of a work item is given the chance to
|
||||
add some information of its own.
|
||||
|
||||
The contents look something like the following:
|
||||
|
||||
THR PID ITEM ADDR FL MARK DESC
|
||||
=== ===== ================ == ===== ==========
|
||||
0 3005 ffff880023f52348 a 952ms FSC: OBJ17d3: LOOK
|
||||
1 3006 ffff880024e33668 2 160ms FSC: OBJ17e5 OP60d3b: Write1/Store fl=2
|
||||
2 3165 ffff8800296dd180 a 424ms FSC: OBJ17e4: LOOK
|
||||
3 4089 ffff8800262c8d78 a 212ms FSC: OBJ17ea: CRTN
|
||||
4 4090 ffff88002792bed8 2 388ms FSC: OBJ17e8 OP60d36: Write1/Store fl=2
|
||||
5 4092 ffff88002a0ef308 2 388ms FSC: OBJ17e7 OP60d2e: Write1/Store fl=2
|
||||
6 4094 ffff88002abaf4b8 2 132ms FSC: OBJ17e2 OP60d4e: Write1/Store fl=2
|
||||
7 4095 ffff88002bb188e0 a 388ms FSC: OBJ17e9: CRTN
|
||||
vsq - ffff880023d99668 1 308ms FSC: OBJ17e0 OP60f91: Write1/EnQ fl=2
|
||||
vsq - ffff8800295d1740 1 212ms FSC: OBJ16be OP4d4b6: Write1/EnQ fl=2
|
||||
vsq - ffff880025ba3308 1 160ms FSC: OBJ179a OP58dec: Write1/EnQ fl=2
|
||||
vsq - ffff880024ec83e0 1 160ms FSC: OBJ17ae OP599f2: Write1/EnQ fl=2
|
||||
vsq - ffff880026618e00 1 160ms FSC: OBJ17e6 OP60d33: Write1/EnQ fl=2
|
||||
vsq - ffff880025a2a4b8 1 132ms FSC: OBJ16a2 OP4d583: Write1/EnQ fl=2
|
||||
vsq - ffff880023cbe6d8 9 212ms FSC: OBJ17eb: LOOK
|
||||
vsq - ffff880024d37590 9 212ms FSC: OBJ17ec: LOOK
|
||||
vsq - ffff880027746cb0 9 212ms FSC: OBJ17ed: LOOK
|
||||
vsq - ffff880024d37ae8 9 212ms FSC: OBJ17ee: LOOK
|
||||
vsq - ffff880024d37cb0 9 212ms FSC: OBJ17ef: LOOK
|
||||
vsq - ffff880025036550 9 212ms FSC: OBJ17f0: LOOK
|
||||
vsq - ffff8800250368e0 9 212ms FSC: OBJ17f1: LOOK
|
||||
vsq - ffff880025036aa8 9 212ms FSC: OBJ17f2: LOOK
|
||||
|
||||
In the 'THR' column, executing items show the thread they're occupying and
|
||||
queued threads indicate which queue they're on. 'PID' shows the process ID of
|
||||
a slow-work thread that's executing something. 'FL' shows the work item flags.
|
||||
'MARK' indicates how long since an item was queued or began executing. Lastly,
|
||||
the 'DESC' column permits the owner of an item to give some information.
|
||||
|
||||
|
|
|
|||
|
|
@ -538,7 +538,7 @@ SPI MESSAGE QUEUE
|
|||
The bulk of the driver will be managing the I/O queue fed by transfer().
|
||||
|
||||
That queue could be purely conceptual. For example, a driver used only
|
||||
for low-frequency sensor acess might be fine using synchronous PIO.
|
||||
for low-frequency sensor access might be fine using synchronous PIO.
|
||||
|
||||
But the queue will probably be very real, using message->queue, PIO,
|
||||
often DMA (especially if the root filesystem is in SPI flash), and
|
||||
|
|
|
|||
|
|
@ -1,22 +0,0 @@
|
|||
|
||||
Except for a few extremely rare exceptions user space applications do not use
|
||||
the binary sysctl interface. Instead everyone uses /proc/sys/... with
|
||||
readable ascii names.
|
||||
|
||||
Recently the kernel has started supporting setting the binary sysctl value to
|
||||
CTL_UNNUMBERED so we no longer need to assign a binary sysctl path to allow
|
||||
sysctls to show up in /proc/sys.
|
||||
|
||||
Assigning binary sysctl numbers is an endless source of conflicts in sysctl.h,
|
||||
breaking of the user space ABI (because of those conflicts), and maintenance
|
||||
problems. A complete pass through all of the sysctl users revealed multiple
|
||||
instances where the sysctl binary interface was broken and had gone undetected
|
||||
for years.
|
||||
|
||||
So please do not add new binary sysctl numbers. They are unneeded and
|
||||
problematic.
|
||||
|
||||
If you really need a new binary sysctl number please first merge your sysctl
|
||||
into the kernel and then as a separate patch allocate a binary sysctl number.
|
||||
|
||||
(ebiederm@xmission.com, June 2007)
|
||||
|
|
@ -139,9 +139,9 @@ core_pattern is used to specify a core dumpfile pattern name.
|
|||
core_pipe_limit:
|
||||
|
||||
This sysctl is only applicable when core_pattern is configured to pipe core
|
||||
files to user space helper a (when the first character of core_pattern is a '|',
|
||||
files to a user space helper (when the first character of core_pattern is a '|',
|
||||
see above). When collecting cores via a pipe to an application, it is
|
||||
occasionally usefull for the collecting application to gather data about the
|
||||
occasionally useful for the collecting application to gather data about the
|
||||
crashing process from its /proc/pid directory. In order to do this safely, the
|
||||
kernel must wait for the collecting process to exit, so as not to remove the
|
||||
crashing processes proc files prematurely. This in turn creates the possibility
|
||||
|
|
@ -152,7 +152,7 @@ applications in parallel. If this value is exceeded, then those crashing
|
|||
processes above that value are noted via the kernel log and their cores are
|
||||
skipped. 0 is a special value, indicating that unlimited processes may be
|
||||
captured in parallel, but that no waiting will take place (i.e. the collecting
|
||||
process is not guaranteed access to /proc/<crahing pid>/). This value defaults
|
||||
process is not guaranteed access to /proc/<crashing pid>/). This value defaults
|
||||
to 0.
|
||||
|
||||
==============================================================
|
||||
|
|
|
|||
|
|
@ -370,7 +370,7 @@ The default is 1 percent.
|
|||
mmap_min_addr
|
||||
|
||||
This file indicates the amount of address space which a user process will
|
||||
be restricted from mmaping. Since kernel null dereference bugs could
|
||||
be restricted from mmapping. Since kernel null dereference bugs could
|
||||
accidentally operate based on the information in the first couple of pages
|
||||
of memory userspace processes should not be allowed to write to them. By
|
||||
default this value is set to 0 and no protections will be enforced by the
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
The High Precision Event Timer (HPET) hardware follows a specification
|
||||
by Intel and Microsoft which can be found at
|
||||
|
||||
http://www.intel.com/technology/architecture/hpetspec.htm
|
||||
http://www.intel.com/hardwaredesign/hpetspec_1.pdf
|
||||
|
||||
Each HPET has one fixed-rate counter (at 10+ MHz, hence "High Precision")
|
||||
and up to 32 comparators. Normally three or more comparators are provided,
|
||||
|
|
|
|||
|
|
@ -213,10 +213,19 @@ If you can't trace NMI functions, then skip this option.
|
|||
<details to be filled>
|
||||
|
||||
|
||||
HAVE_FTRACE_SYSCALLS
|
||||
HAVE_SYSCALL_TRACEPOINTS
|
||||
---------------------
|
||||
|
||||
<details to be filled>
|
||||
You need very few things to get the syscalls tracing in an arch.
|
||||
|
||||
- Have a NR_syscalls variable in <asm/unistd.h> that provides the number
|
||||
of syscalls supported by the arch.
|
||||
- Implement arch_syscall_addr() that resolves a syscall address from a
|
||||
syscall number.
|
||||
- Support the TIF_SYSCALL_TRACEPOINT thread flags
|
||||
- Put the trace_sys_enter() and trace_sys_exit() tracepoints calls from ptrace
|
||||
in the ptrace syscalls tracing path.
|
||||
- Tag this arch as HAVE_SYSCALL_TRACEPOINTS.
|
||||
|
||||
|
||||
HAVE_FTRACE_MCOUNT_RECORD
|
||||
|
|
|
|||
|
|
@ -0,0 +1,149 @@
|
|||
Kprobe-based Event Tracing
|
||||
==========================
|
||||
|
||||
Documentation is written by Masami Hiramatsu
|
||||
|
||||
|
||||
Overview
|
||||
--------
|
||||
These events are similar to tracepoint based events. Instead of Tracepoint,
|
||||
this is based on kprobes (kprobe and kretprobe). So it can probe wherever
|
||||
kprobes can probe (this means, all functions body except for __kprobes
|
||||
functions). Unlike the Tracepoint based event, this can be added and removed
|
||||
dynamically, on the fly.
|
||||
|
||||
To enable this feature, build your kernel with CONFIG_KPROBE_TRACING=y.
|
||||
|
||||
Similar to the events tracer, this doesn't need to be activated via
|
||||
current_tracer. Instead of that, add probe points via
|
||||
/sys/kernel/debug/tracing/kprobe_events, and enable it via
|
||||
/sys/kernel/debug/tracing/events/kprobes/<EVENT>/enabled.
|
||||
|
||||
|
||||
Synopsis of kprobe_events
|
||||
-------------------------
|
||||
p[:[GRP/]EVENT] SYMBOL[+offs]|MEMADDR [FETCHARGS] : Set a probe
|
||||
r[:[GRP/]EVENT] SYMBOL[+0] [FETCHARGS] : Set a return probe
|
||||
|
||||
GRP : Group name. If omitted, use "kprobes" for it.
|
||||
EVENT : Event name. If omitted, the event name is generated
|
||||
based on SYMBOL+offs or MEMADDR.
|
||||
SYMBOL[+offs] : Symbol+offset where the probe is inserted.
|
||||
MEMADDR : Address where the probe is inserted.
|
||||
|
||||
FETCHARGS : Arguments. Each probe can have up to 128 args.
|
||||
%REG : Fetch register REG
|
||||
@ADDR : Fetch memory at ADDR (ADDR should be in kernel)
|
||||
@SYM[+|-offs] : Fetch memory at SYM +|- offs (SYM should be a data symbol)
|
||||
$stackN : Fetch Nth entry of stack (N >= 0)
|
||||
$stack : Fetch stack address.
|
||||
$argN : Fetch function argument. (N >= 0)(*)
|
||||
$retval : Fetch return value.(**)
|
||||
+|-offs(FETCHARG) : Fetch memory at FETCHARG +|- offs address.(***)
|
||||
NAME=FETCHARG: Set NAME as the argument name of FETCHARG.
|
||||
|
||||
(*) aN may not correct on asmlinkaged functions and at the middle of
|
||||
function body.
|
||||
(**) only for return probe.
|
||||
(***) this is useful for fetching a field of data structures.
|
||||
|
||||
|
||||
Per-Probe Event Filtering
|
||||
-------------------------
|
||||
Per-probe event filtering feature allows you to set different filter on each
|
||||
probe and gives you what arguments will be shown in trace buffer. If an event
|
||||
name is specified right after 'p:' or 'r:' in kprobe_events, it adds an event
|
||||
under tracing/events/kprobes/<EVENT>, at the directory you can see 'id',
|
||||
'enabled', 'format' and 'filter'.
|
||||
|
||||
enabled:
|
||||
You can enable/disable the probe by writing 1 or 0 on it.
|
||||
|
||||
format:
|
||||
This shows the format of this probe event.
|
||||
|
||||
filter:
|
||||
You can write filtering rules of this event.
|
||||
|
||||
id:
|
||||
This shows the id of this probe event.
|
||||
|
||||
|
||||
Event Profiling
|
||||
---------------
|
||||
You can check the total number of probe hits and probe miss-hits via
|
||||
/sys/kernel/debug/tracing/kprobe_profile.
|
||||
The first column is event name, the second is the number of probe hits,
|
||||
the third is the number of probe miss-hits.
|
||||
|
||||
|
||||
Usage examples
|
||||
--------------
|
||||
To add a probe as a new event, write a new definition to kprobe_events
|
||||
as below.
|
||||
|
||||
echo p:myprobe do_sys_open dfd=$arg0 filename=$arg1 flags=$arg2 mode=$arg3 > /sys/kernel/debug/tracing/kprobe_events
|
||||
|
||||
This sets a kprobe on the top of do_sys_open() function with recording
|
||||
1st to 4th arguments as "myprobe" event. As this example shows, users can
|
||||
choose more familiar names for each arguments.
|
||||
|
||||
echo r:myretprobe do_sys_open $retval >> /sys/kernel/debug/tracing/kprobe_events
|
||||
|
||||
This sets a kretprobe on the return point of do_sys_open() function with
|
||||
recording return value as "myretprobe" event.
|
||||
You can see the format of these events via
|
||||
/sys/kernel/debug/tracing/events/kprobes/<EVENT>/format.
|
||||
|
||||
cat /sys/kernel/debug/tracing/events/kprobes/myprobe/format
|
||||
name: myprobe
|
||||
ID: 75
|
||||
format:
|
||||
field:unsigned short common_type; offset:0; size:2;
|
||||
field:unsigned char common_flags; offset:2; size:1;
|
||||
field:unsigned char common_preempt_count; offset:3; size:1;
|
||||
field:int common_pid; offset:4; size:4;
|
||||
field:int common_tgid; offset:8; size:4;
|
||||
|
||||
field: unsigned long ip; offset:16;tsize:8;
|
||||
field: int nargs; offset:24;tsize:4;
|
||||
field: unsigned long dfd; offset:32;tsize:8;
|
||||
field: unsigned long filename; offset:40;tsize:8;
|
||||
field: unsigned long flags; offset:48;tsize:8;
|
||||
field: unsigned long mode; offset:56;tsize:8;
|
||||
|
||||
print fmt: "(%lx) dfd=%lx filename=%lx flags=%lx mode=%lx", REC->ip, REC->dfd, REC->filename, REC->flags, REC->mode
|
||||
|
||||
|
||||
You can see that the event has 4 arguments as in the expressions you specified.
|
||||
|
||||
echo > /sys/kernel/debug/tracing/kprobe_events
|
||||
|
||||
This clears all probe points.
|
||||
|
||||
Right after definition, each event is disabled by default. For tracing these
|
||||
events, you need to enable it.
|
||||
|
||||
echo 1 > /sys/kernel/debug/tracing/events/kprobes/myprobe/enable
|
||||
echo 1 > /sys/kernel/debug/tracing/events/kprobes/myretprobe/enable
|
||||
|
||||
And you can see the traced information via /sys/kernel/debug/tracing/trace.
|
||||
|
||||
cat /sys/kernel/debug/tracing/trace
|
||||
# tracer: nop
|
||||
#
|
||||
# TASK-PID CPU# TIMESTAMP FUNCTION
|
||||
# | | | | |
|
||||
<...>-1447 [001] 1038282.286875: myprobe: (do_sys_open+0x0/0xd6) dfd=3 filename=7fffd1ec4440 flags=8000 mode=0
|
||||
<...>-1447 [001] 1038282.286878: myretprobe: (sys_openat+0xc/0xe <- do_sys_open) $retval=fffffffffffffffe
|
||||
<...>-1447 [001] 1038282.286885: myprobe: (do_sys_open+0x0/0xd6) dfd=ffffff9c filename=40413c flags=8000 mode=1b6
|
||||
<...>-1447 [001] 1038282.286915: myretprobe: (sys_open+0x1b/0x1d <- do_sys_open) $retval=3
|
||||
<...>-1447 [001] 1038282.286969: myprobe: (do_sys_open+0x0/0xd6) dfd=ffffff9c filename=4041c6 flags=98800 mode=10
|
||||
<...>-1447 [001] 1038282.286976: myretprobe: (sys_open+0x1b/0x1d <- do_sys_open) $retval=3
|
||||
|
||||
|
||||
Each line shows when the kernel hits an event, and <- SYMBOL means kernel
|
||||
returns from SYMBOL(e.g. "sys_open+0x1b/0x1d <- do_sys_open" means kernel
|
||||
returns from do_sys_open to sys_open+0x1b).
|
||||
|
||||
|
||||
|
|
@ -24,3 +24,5 @@
|
|||
23 -> Magic-Pro ProHDTV Extreme 2 [14f1:8657]
|
||||
24 -> Hauppauge WinTV-HVR1850 [0070:8541]
|
||||
25 -> Compro VideoMate E800 [1858:e800]
|
||||
26 -> Hauppauge WinTV-HVR1290 [0070:8551]
|
||||
27 -> Mygica X8558 PRO DMB-TH [14f1:8578]
|
||||
|
|
|
|||
|
|
@ -81,3 +81,4 @@
|
|||
80 -> Hauppauge WinTV-IR Only [0070:9290]
|
||||
81 -> Leadtek WinFast DTV1800 Hybrid [107d:6654]
|
||||
82 -> WinFast DTV2000 H rev. J [107d:6f2b]
|
||||
83 -> Prof 7301 DVB-S/S2 [b034:3034]
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
0 -> Unknown EM2800 video grabber (em2800) [eb1a:2800]
|
||||
1 -> Unknown EM2750/28xx video grabber (em2820/em2840) [eb1a:2710,eb1a:2820,eb1a:2821,eb1a:2860,eb1a:2861,eb1a:2870,eb1a:2881,eb1a:2883,eb1a:2868]
|
||||
1 -> Unknown EM2750/28xx video grabber (em2820/em2840) [eb1a:2710,eb1a:2820,eb1a:2821,eb1a:2860,eb1a:2861,eb1a:2862,eb1a:2870,eb1a:2881,eb1a:2883,eb1a:2868]
|
||||
2 -> Terratec Cinergy 250 USB (em2820/em2840) [0ccd:0036]
|
||||
3 -> Pinnacle PCTV USB 2 (em2820/em2840) [2304:0208]
|
||||
4 -> Hauppauge WinTV USB 2 (em2820/em2840) [2040:4200,2040:4201]
|
||||
|
|
@ -69,3 +69,4 @@
|
|||
71 -> Silvercrest Webcam 1.3mpix (em2820/em2840)
|
||||
72 -> Gadmei UTV330+ (em2861)
|
||||
73 -> Reddo DVB-C USB TV Box (em2870)
|
||||
74 -> Actionmaster/LinXcel/Digitus VC211A (em2800)
|
||||
|
|
|
|||
|
|
@ -172,3 +172,5 @@
|
|||
171 -> Beholder BeholdTV X7 [5ace:7595]
|
||||
172 -> RoverMedia TV Link Pro FM [19d1:0138]
|
||||
173 -> Zolid Hybrid TV Tuner PCI [1131:2004]
|
||||
174 -> Asus Europa Hybrid OEM [1043:4847]
|
||||
175 -> Leadtek Winfast DTV1000S [107d:6655]
|
||||
|
|
|
|||
|
|
@ -6,7 +6,8 @@ The modules are:
|
|||
|
||||
xxxx vend:prod
|
||||
----
|
||||
spca501 0000:0000 MystFromOri Unknow Camera
|
||||
spca501 0000:0000 MystFromOri Unknown Camera
|
||||
spca508 0130:0130 Clone Digital Webcam 11043
|
||||
m5602 0402:5602 ALi Video Camera Controller
|
||||
spca501 040a:0002 Kodak DVC-325
|
||||
spca500 040a:0300 Kodak EZ200
|
||||
|
|
@ -37,6 +38,7 @@ ov519 041e:405f Creative Live! VISTA VF0330
|
|||
ov519 041e:4060 Creative Live! VISTA VF0350
|
||||
ov519 041e:4061 Creative Live! VISTA VF0400
|
||||
ov519 041e:4064 Creative Live! VISTA VF0420
|
||||
ov519 041e:4067 Creative Live! Cam Video IM (VF0350)
|
||||
ov519 041e:4068 Creative Live! VISTA VF0470
|
||||
spca561 0458:7004 Genius VideoCAM Express V2
|
||||
sunplus 0458:7006 Genius Dsc 1.3 Smart
|
||||
|
|
@ -68,12 +70,12 @@ zc3xx 046d:08a3 Logitech QC Chat
|
|||
zc3xx 046d:08a6 Logitech QCim
|
||||
zc3xx 046d:08a7 Logitech QuickCam Image
|
||||
zc3xx 046d:08a9 Logitech Notebook Deluxe
|
||||
zc3xx 046d:08aa Labtec Webcam Notebook
|
||||
zc3xx 046d:08aa Labtec Webcam Notebook
|
||||
zc3xx 046d:08ac Logitech QuickCam Cool
|
||||
zc3xx 046d:08ad Logitech QCCommunicate STX
|
||||
zc3xx 046d:08ae Logitech QuickCam for Notebooks
|
||||
zc3xx 046d:08af Logitech QuickCam Cool
|
||||
zc3xx 046d:08b9 Logitech QC IM ???
|
||||
zc3xx 046d:08b9 Logitech QuickCam Express
|
||||
zc3xx 046d:08d7 Logitech QCam STX
|
||||
zc3xx 046d:08d9 Logitech QuickCam IM/Connect
|
||||
zc3xx 046d:08d8 Logitech Notebook Deluxe
|
||||
|
|
@ -82,7 +84,7 @@ zc3xx 046d:08dd Logitech QuickCam for Notebooks
|
|||
spca500 046d:0900 Logitech Inc. ClickSmart 310
|
||||
spca500 046d:0901 Logitech Inc. ClickSmart 510
|
||||
sunplus 046d:0905 Logitech ClickSmart 820
|
||||
tv8532 046d:0920 QC Express
|
||||
tv8532 046d:0920 Logitech QuickCam Express
|
||||
tv8532 046d:0921 Labtec Webcam
|
||||
spca561 046d:0928 Logitech QC Express Etch2
|
||||
spca561 046d:0929 Labtec Webcam Elch2
|
||||
|
|
@ -91,7 +93,7 @@ spca561 046d:092b Labtec Webcam Plus
|
|||
spca561 046d:092c Logitech QC chat Elch2
|
||||
spca561 046d:092d Logitech QC Elch2
|
||||
spca561 046d:092e Logitech QC Elch2
|
||||
spca561 046d:092f Logitech QuickCam Express Plus
|
||||
spca561 046d:092f Logitech QuickCam Express Plus
|
||||
sunplus 046d:0960 Logitech ClickSmart 420
|
||||
sunplus 0471:0322 Philips DMVC1300K
|
||||
zc3xx 0471:0325 Philips SPC 200 NC
|
||||
|
|
@ -187,7 +189,6 @@ sonixj 06f8:3004 Hercules Classic Silver
|
|||
sonixj 06f8:3008 Hercules Deluxe Optical Glass
|
||||
pac7311 06f8:3009 Hercules Classic Link
|
||||
spca508 0733:0110 ViewQuest VQ110
|
||||
spca508 0130:0130 Clone Digital Webcam 11043
|
||||
spca501 0733:0401 Intel Create and Share
|
||||
spca501 0733:0402 ViewQuest M318B
|
||||
spca505 0733:0430 Intel PC Camera Pro
|
||||
|
|
@ -202,6 +203,7 @@ spca500 084d:0003 D-Link DSC-350
|
|||
spca500 08ca:0103 Aiptek PocketDV
|
||||
sunplus 08ca:0104 Aiptek PocketDVII 1.3
|
||||
sunplus 08ca:0106 Aiptek Pocket DV3100+
|
||||
mr97310a 08ca:0110 Trust Spyc@m 100
|
||||
mr97310a 08ca:0111 Aiptek PenCam VGA+
|
||||
sunplus 08ca:2008 Aiptek Mini PenCam 2 M
|
||||
sunplus 08ca:2010 Aiptek PocketCam 3M
|
||||
|
|
@ -222,7 +224,7 @@ pac207 093a:2460 Qtec Webcam 100
|
|||
pac207 093a:2461 HP Webcam
|
||||
pac207 093a:2463 Philips SPC 220 NC
|
||||
pac207 093a:2464 Labtec Webcam 1200
|
||||
pac207 093a:2468 PAC207
|
||||
pac207 093a:2468 Webcam WB-1400T
|
||||
pac207 093a:2470 Genius GF112
|
||||
pac207 093a:2471 Genius VideoCam ge111
|
||||
pac207 093a:2472 Genius VideoCam ge110
|
||||
|
|
@ -230,7 +232,7 @@ pac207 093a:2474 Genius iLook 111
|
|||
pac207 093a:2476 Genius e-Messenger 112
|
||||
pac7311 093a:2600 PAC7311 Typhoon
|
||||
pac7311 093a:2601 Philips SPC 610 NC
|
||||
pac7311 093a:2603 PAC7312
|
||||
pac7311 093a:2603 Philips SPC 500 NC
|
||||
pac7311 093a:2608 Trust WB-3300p
|
||||
pac7311 093a:260e Gigaware VGA PC Camera, Trust WB-3350p, SIGMA cam 2350
|
||||
pac7311 093a:260f SnakeCam
|
||||
|
|
@ -239,6 +241,7 @@ pac7311 093a:2621 PAC731x
|
|||
pac7311 093a:2622 Genius Eye 312
|
||||
pac7311 093a:2624 PAC7302
|
||||
pac7311 093a:2626 Labtec 2200
|
||||
pac7311 093a:2628 Genius iLook 300
|
||||
pac7311 093a:2629 Genious iSlim 300
|
||||
pac7311 093a:262a Webcam 300k
|
||||
pac7311 093a:262c Philips SPC 230 NC
|
||||
|
|
@ -250,7 +253,7 @@ vc032x 0ac8:0328 A4Tech PK-130MG
|
|||
zc3xx 0ac8:301b Z-Star zc301b
|
||||
zc3xx 0ac8:303b Vimicro 0x303b
|
||||
zc3xx 0ac8:305b Z-star Vimicro zc0305b
|
||||
zc3xx 0ac8:307b Ldlc VC302+Ov7620
|
||||
zc3xx 0ac8:307b PC Camera (ZS0211)
|
||||
vc032x 0ac8:c001 Sony embedded vimicro
|
||||
vc032x 0ac8:c002 Sony embedded vimicro
|
||||
vc032x 0ac8:c301 Samsung Q1 Ultra Premium
|
||||
|
|
|
|||
|
|
@ -164,7 +164,7 @@ Stereo/Mono and RDS subchannels
|
|||
|
||||
The device can also be configured using the available sub channels for
|
||||
transmission. To do that use S/G_MODULATOR ioctl and configure txsubchans properly.
|
||||
Refer to v4l2-spec for proper use of this ioctl.
|
||||
Refer to the V4L2 API specification for proper use of this ioctl.
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
|
|
|||
|
|
@ -66,3 +66,4 @@ Vendor Product Distributor Model
|
|||
0x0a17 0x004e Pentax Optio 50
|
||||
0x041e 0x405d Creative DiVi CAM 516
|
||||
0x08ca 0x2102 Aiptek DV T300
|
||||
0x06d6 0x003d Trust Powerc@m 910Z
|
||||
|
|
|
|||
|
|
@ -301,7 +301,7 @@ static char *page_flag_name(uint64_t flags)
|
|||
present = (flags >> i) & 1;
|
||||
if (!page_flag_names[i]) {
|
||||
if (present)
|
||||
fatal("unkown flag bit %d\n", i);
|
||||
fatal("unknown flag bit %d\n", i);
|
||||
continue;
|
||||
}
|
||||
buf[j++] = present ? page_flag_names[i][0] : '_';
|
||||
|
|
|
|||
|
|
@ -245,7 +245,7 @@ been overwritten. Here a string of 8 characters was written into a slab that
|
|||
has the length of 8 characters. However, a 8 character string needs a
|
||||
terminating 0. That zero has overwritten the first byte of the Redzone field.
|
||||
After reporting the details of the issue encountered the FIX SLUB message
|
||||
tell us that SLUB has restored the Redzone to its proper value and then
|
||||
tells us that SLUB has restored the Redzone to its proper value and then
|
||||
system operations continue.
|
||||
|
||||
Emergency operations:
|
||||
|
|
|
|||
162
MAINTAINERS
162
MAINTAINERS
|
|
@ -327,6 +327,13 @@ M: Colin Leroy <colin@colino.net>
|
|||
S: Maintained
|
||||
F: drivers/macintosh/therm_adt746x.c
|
||||
|
||||
ADT7475 HARDWARE MONITOR DRIVER
|
||||
M: Jean Delvare <khali@linux-fr.org>
|
||||
L: lm-sensors@lm-sensors.org
|
||||
S: Maintained
|
||||
F: Documentation/hwmon/adt7475
|
||||
F: drivers/hwmon/adt7475.c
|
||||
|
||||
ADVANSYS SCSI DRIVER
|
||||
M: Matthew Wilcox <matthew@wil.cx>
|
||||
L: linux-scsi@vger.kernel.org
|
||||
|
|
@ -486,13 +493,6 @@ S: Maintained
|
|||
F: drivers/net/appletalk/
|
||||
F: net/appletalk/
|
||||
|
||||
APPLETOUCH TOUCHPAD DRIVER
|
||||
M: Johannes Berg <johannes@sipsolutions.net>
|
||||
L: linux-input@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/input/appletouch.txt
|
||||
F: drivers/input/mouse/appletouch.c
|
||||
|
||||
ARC FRAMEBUFFER DRIVER
|
||||
M: Jaya Kumar <jayalk@intworks.biz>
|
||||
S: Maintained
|
||||
|
|
@ -512,10 +512,32 @@ W: http://www.arm.linux.org.uk/
|
|||
S: Maintained
|
||||
F: arch/arm/
|
||||
|
||||
ARM PRIMECELL AACI PL041 DRIVER
|
||||
M: Russell King <linux@arm.linux.org.uk>
|
||||
S: Maintained
|
||||
F: sound/arm/aaci.*
|
||||
|
||||
ARM PRIMECELL CLCD PL110 DRIVER
|
||||
M: Russell King <linux@arm.linux.org.uk>
|
||||
S: Maintained
|
||||
F: drivers/video/amba-clcd.*
|
||||
|
||||
ARM PRIMECELL KMI PL050 DRIVER
|
||||
M: Russell King <linux@arm.linux.org.uk>
|
||||
S: Maintained
|
||||
F: drivers/input/serio/ambakmi.*
|
||||
F: include/linux/amba/kmi.h
|
||||
|
||||
ARM PRIMECELL MMCI PL180/1 DRIVER
|
||||
S: Orphan
|
||||
F: drivers/mmc/host/mmci.*
|
||||
|
||||
ARM PRIMECELL BUS SUPPORT
|
||||
M: Russell King <linux@arm.linux.org.uk>
|
||||
S: Maintained
|
||||
F: drivers/amba/
|
||||
F: include/linux/amba/bus.h
|
||||
|
||||
ARM/ADI ROADRUNNER MACHINE SUPPORT
|
||||
M: Lennert Buytenhek <kernel@wantstofly.org>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
|
|
@ -637,6 +659,9 @@ ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
|
|||
M: Sascha Hauer <kernel@pengutronix.de>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
T: git://git.pengutronix.de/git/imx/linux-2.6.git
|
||||
F: arch/arm/mach-mx*/
|
||||
F: arch/arm/plat-mxc/
|
||||
|
||||
ARM/GLOMATION GESBC9312SX MACHINE SUPPORT
|
||||
M: Lennert Buytenhek <kernel@wantstofly.org>
|
||||
|
|
@ -707,6 +732,19 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
|||
S: Maintained
|
||||
F: arch/arm/mach-ixp4xx/
|
||||
|
||||
ARM/INTEL RESEARCH IMOTE 2 MACHINE SUPPORT
|
||||
M: Jonathan Cameron <jic23@cam.ac.uk>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: arch/arm/mach-pxa/imote2.c
|
||||
|
||||
ARM/INTEL RESEARCH STARGATE 2 MACHINE SUPPORT
|
||||
M: Jonathan Cameron <jic23@cam.ac.uk>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: arch/arm/mach-pxa/stargate2.c
|
||||
F: drivers/pcmcia/pxa2xx_stargate2.c
|
||||
|
||||
ARM/INTEL XSC3 (MANZANO) ARM CORE
|
||||
M: Lennert Buytenhek <kernel@wantstofly.org>
|
||||
M: Dan Williams <dan.j.williams@intel.com>
|
||||
|
|
@ -749,6 +787,14 @@ ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT
|
|||
M: Michael Petchkovsky <mkpetch@internode.on.net>
|
||||
S: Maintained
|
||||
|
||||
ARM/NOMADIK ARCHITECTURE
|
||||
M: Alessandro Rubini <rubini@unipv.it>
|
||||
M: STEricsson <STEricsson_nomadik_linux@list.st.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: arch/arm/mach-nomadik/
|
||||
F: arch/arm/plat-nomadik/
|
||||
|
||||
ARM/OPENMOKO NEO FREERUNNER (GTA02) MACHINE SUPPORT
|
||||
M: Nelson Castillo <arhuaco@freaks-unidos.net>
|
||||
L: openmoko-kernel@lists.openmoko.org (subscribers-only)
|
||||
|
|
@ -893,6 +939,12 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
|||
W: http://www.mcuos.com
|
||||
S: Maintained
|
||||
|
||||
ARM/U8500 ARM ARCHITECTURE
|
||||
M: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: arch/arm/mach-ux500/
|
||||
|
||||
ARM/VFP SUPPORT
|
||||
M: Russell King <linux@arm.linux.org.uk>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
|
|
@ -1027,7 +1079,7 @@ F: drivers/serial/atmel_serial.c
|
|||
|
||||
ATMEL LCDFB DRIVER
|
||||
M: Nicolas Ferre <nicolas.ferre@atmel.com>
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/video/atmel_lcdfb.c
|
||||
F: include/video/atmel_lcdc.h
|
||||
|
|
@ -1098,7 +1150,6 @@ F: include/net/ax25.h
|
|||
F: net/ax25/
|
||||
|
||||
B43 WIRELESS DRIVER
|
||||
M: Michael Buesch <mb@bu3sch.de>
|
||||
M: Stefano Brivio <stefano.brivio@polimi.it>
|
||||
L: linux-wireless@vger.kernel.org
|
||||
W: http://linuxwireless.org/en/users/Drivers/b43
|
||||
|
|
@ -1797,6 +1848,19 @@ S: Maintained
|
|||
F: drivers/scsi/dpt*
|
||||
F: drivers/scsi/dpt/
|
||||
|
||||
DRBD DRIVER
|
||||
P: Philipp Reisner
|
||||
P: Lars Ellenberg
|
||||
M: drbd-dev@lists.linbit.com
|
||||
L: drbd-user@lists.linbit.com
|
||||
W: http://www.drbd.org
|
||||
T: git git://git.drbd.org/linux-2.6-drbd.git drbd
|
||||
T: git git://git.drbd.org/drbd-8.3.git
|
||||
S: Supported
|
||||
F: drivers/block/drbd/
|
||||
F: lib/lru_cache.c
|
||||
F: Documentation/blockdev/drbd/
|
||||
|
||||
DRIVER CORE, KOBJECTS, AND SYSFS
|
||||
M: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
T: quilt kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
|
||||
|
|
@ -2113,7 +2177,7 @@ F: drivers/net/wan/dlci.c
|
|||
F: drivers/net/wan/sdla.c
|
||||
|
||||
FRAMEBUFFER LAYER
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
W: http://linux-fbdev.sourceforge.net/
|
||||
S: Orphan
|
||||
F: Documentation/fb/
|
||||
|
|
@ -2136,7 +2200,7 @@ F: drivers/i2c/busses/i2c-cpm.c
|
|||
|
||||
FREESCALE IMX / MXC FRAMEBUFFER DRIVER
|
||||
M: Sascha Hauer <kernel@pengutronix.de>
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: arch/arm/plat-mxc/include/mach/imxfb.h
|
||||
|
|
@ -2312,6 +2376,13 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
|||
S: Maintained
|
||||
F: drivers/media/video/gspca/finepix.c
|
||||
|
||||
GSPCA GL860 SUBDRIVER
|
||||
M: Olivier Lorin <o.lorin@laposte.net>
|
||||
L: linux-media@vger.kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
S: Maintained
|
||||
F: drivers/media/video/gspca/gl860/
|
||||
|
||||
GSPCA M5602 SUBDRIVER
|
||||
M: Erik Andren <erik.andren@gmail.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
|
|
@ -2352,7 +2423,9 @@ HARDWARE MONITORING
|
|||
L: lm-sensors@lm-sensors.org
|
||||
W: http://www.lm-sensors.org/
|
||||
S: Orphan
|
||||
F: Documentation/hwmon/
|
||||
F: drivers/hwmon/
|
||||
F: include/linux/hwmon*.h
|
||||
|
||||
HARDWARE RANDOM NUMBER GENERATOR CORE
|
||||
M: Matt Mackall <mpm@selenic.com>
|
||||
|
|
@ -2533,8 +2606,7 @@ S: Maintained
|
|||
F: Documentation/i2c/
|
||||
F: drivers/i2c/
|
||||
F: include/linux/i2c.h
|
||||
F: include/linux/i2c-dev.h
|
||||
F: include/linux/i2c-id.h
|
||||
F: include/linux/i2c-*.h
|
||||
|
||||
I2C-TINY-USB DRIVER
|
||||
M: Till Harbaum <till@harbaum.org>
|
||||
|
|
@ -2635,7 +2707,7 @@ S: Supported
|
|||
F: security/integrity/ima/
|
||||
|
||||
IMS TWINTURBO FRAMEBUFFER DRIVER
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
S: Orphan
|
||||
F: drivers/video/imsttfb.c
|
||||
|
||||
|
|
@ -2670,14 +2742,14 @@ F: drivers/input/
|
|||
|
||||
INTEL FRAMEBUFFER DRIVER (excluding 810 and 815)
|
||||
M: Sylvain Meyer <sylvain.meyer@worldonline.fr>
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/fb/intelfb.txt
|
||||
F: drivers/video/intelfb/
|
||||
|
||||
INTEL 810/815 FRAMEBUFFER DRIVER
|
||||
M: Antonino Daplas <adaplas@gmail.com>
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/video/i810/
|
||||
|
||||
|
|
@ -2789,6 +2861,15 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-2.6.git
|
|||
S: Supported
|
||||
F: drivers/net/wireless/iwlwifi/
|
||||
|
||||
INTEL WIRELESS MULTICOMM 3200 WIFI (iwmc3200wifi)
|
||||
M: Samuel Ortiz <samuel.ortiz@intel.com>
|
||||
M: Zhu Yi <yi.zhu@intel.com>
|
||||
M: Intel Linux Wireless <ilw@linux.intel.com>
|
||||
L: linux-wireless@vger.kernel.org
|
||||
S: Supported
|
||||
W: http://wireless.kernel.org/en/users/Drivers/iwmc3200wifi
|
||||
F: drivers/net/wireless/iwmc3200wifi/
|
||||
|
||||
IOC3 ETHERNET DRIVER
|
||||
M: Ralf Baechle <ralf@linux-mips.org>
|
||||
L: linux-mips@linux-mips.org
|
||||
|
|
@ -2987,11 +3068,8 @@ S: Maintained
|
|||
F: fs/autofs4/
|
||||
|
||||
KERNEL BUILD
|
||||
M: Sam Ravnborg <sam@ravnborg.org>
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild-next.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild-fixes.git
|
||||
L: linux-kbuild@vger.kernel.org
|
||||
S: Maintained
|
||||
S: Orphan
|
||||
F: Documentation/kbuild/
|
||||
F: Makefile
|
||||
F: scripts/Makefile.*
|
||||
|
|
@ -3063,6 +3141,7 @@ S: Supported
|
|||
F: Documentation/s390/kvm.txt
|
||||
F: arch/s390/include/asm/kvm*
|
||||
F: arch/s390/kvm/
|
||||
F: drivers/s390/kvm/
|
||||
|
||||
KEXEC
|
||||
M: Eric Biederman <ebiederm@xmission.com>
|
||||
|
|
@ -3242,6 +3321,12 @@ S: Maintained
|
|||
F: Documentation/hwmon/lis3lv02d
|
||||
F: drivers/hwmon/lis3lv02d.*
|
||||
|
||||
LM73 HARDWARE MONITOR DRIVER
|
||||
M: Guillaume Ligneul <guillaume.ligneul@gmail.com>
|
||||
L: lm-sensors@lm-sensors.org
|
||||
S: Maintained
|
||||
F: drivers/hwmon/lm73.c
|
||||
|
||||
LM83 HARDWARE MONITOR DRIVER
|
||||
M: Jean Delvare <khali@linux-fr.org>
|
||||
L: lm-sensors@lm-sensors.org
|
||||
|
|
@ -3391,7 +3476,7 @@ S: Supported
|
|||
|
||||
MATROX FRAMEBUFFER DRIVER
|
||||
M: Petr Vandrovec <vandrove@vc.cvut.cz>
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/video/matrox/matroxfb_*
|
||||
F: include/linux/matroxfb.h
|
||||
|
|
@ -3716,9 +3801,9 @@ F: include/linux/if_*
|
|||
F: include/linux/*device.h
|
||||
|
||||
NETXEN (1/10) GbE SUPPORT
|
||||
M: Dhananjay Phadke <dhananjay@netxen.com>
|
||||
M: Amit Kumar Salecha <amit.salecha@qlogic.com>
|
||||
L: netdev@vger.kernel.org
|
||||
W: http://www.netxen.com
|
||||
W: http://www.qlogic.com
|
||||
S: Supported
|
||||
F: drivers/net/netxen/
|
||||
|
||||
|
|
@ -3778,7 +3863,7 @@ F: fs/ntfs/
|
|||
|
||||
NVIDIA (rivafb and nvidiafb) FRAMEBUFFER DRIVER
|
||||
M: Antonino Daplas <adaplas@gmail.com>
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/video/riva/
|
||||
F: drivers/video/nvidia/
|
||||
|
|
@ -3813,7 +3898,7 @@ F: sound/soc/omap/
|
|||
|
||||
OMAP FRAMEBUFFER SUPPORT
|
||||
M: Imre Deak <imre.deak@nokia.com>
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
L: linux-omap@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/video/omap/
|
||||
|
|
@ -4119,6 +4204,13 @@ W: http://www.pmc-sierra.com/
|
|||
S: Supported
|
||||
F: drivers/scsi/pmcraid.*
|
||||
|
||||
PMC SIERRA PM8001 DRIVER
|
||||
M: jack_wang@usish.com
|
||||
M: lindar_liu@usish.com
|
||||
L: linux-scsi@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/scsi/pm8001/
|
||||
|
||||
POSIX CLOCKS and TIMERS
|
||||
M: Thomas Gleixner <tglx@linutronix.de>
|
||||
S: Supported
|
||||
|
|
@ -4319,14 +4411,14 @@ F: include/linux/qnxtypes.h
|
|||
|
||||
RADEON FRAMEBUFFER DISPLAY DRIVER
|
||||
M: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/video/aty/radeon*
|
||||
F: include/linux/radeonfb.h
|
||||
|
||||
RAGE128 FRAMEBUFFER DISPLAY DRIVER
|
||||
M: Paul Mackerras <paulus@samba.org>
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/video/aty/aty128fb.c
|
||||
|
||||
|
|
@ -4465,7 +4557,7 @@ F: drivers/net/wireless/rtl818x/rtl8187*
|
|||
|
||||
S3 SAVAGE FRAMEBUFFER DRIVER
|
||||
M: Antonino Daplas <adaplas@gmail.com>
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/video/savage/
|
||||
|
||||
|
|
@ -4477,6 +4569,7 @@ L: linux-s390@vger.kernel.org
|
|||
W: http://www.ibm.com/developerworks/linux/linux390/
|
||||
S: Supported
|
||||
F: arch/s390/
|
||||
F: drivers/s390/
|
||||
|
||||
S390 NETWORK DRIVERS
|
||||
M: Ursula Braun <ursula.braun@de.ibm.com>
|
||||
|
|
@ -4492,6 +4585,7 @@ M: Felix Beck <felix.beck@de.ibm.com>
|
|||
M: Ralph Wuerthner <ralph.wuerthner@de.ibm.com>
|
||||
M: linux390@de.ibm.com
|
||||
L: linux-s390@vger.kernel.org
|
||||
W: http://www.ibm.com/developerworks/linux/linux390/
|
||||
S: Supported
|
||||
F: drivers/s390/crypto/
|
||||
|
||||
|
|
@ -5628,7 +5722,7 @@ S: Maintained
|
|||
|
||||
UVESAFB DRIVER
|
||||
M: Michal Januszewski <spock@gentoo.org>
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
W: http://dev.gentoo.org/~spock/projects/uvesafb/
|
||||
S: Maintained
|
||||
F: Documentation/fb/uvesafb.txt
|
||||
|
|
@ -5661,7 +5755,7 @@ F: drivers/mmc/host/via-sdmmc.c
|
|||
VIA UNICHROME(PRO)/CHROME9 FRAMEBUFFER DRIVER
|
||||
M: Joseph Chan <JosephChan@via.com.tw>
|
||||
M: Scott Fang <ScottFang@viatech.com.cn>
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/video/via/
|
||||
|
||||
|
|
@ -5693,6 +5787,14 @@ L: netdev@vger.kernel.org
|
|||
S: Maintained
|
||||
F: drivers/net/vmxnet3/
|
||||
|
||||
VMware PVSCSI driver
|
||||
M: Alok Kataria <akataria@vmware.com>
|
||||
M: VMware PV-Drivers <pv-drivers@vmware.com>
|
||||
L: linux-scsi@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/scsi/vmw_pvscsi.c
|
||||
F: drivers/scsi/vmw_pvscsi.h
|
||||
|
||||
VOLTAGE AND CURRENT REGULATOR FRAMEWORK
|
||||
M: Liam Girdwood <lrg@slimlogic.co.uk>
|
||||
M: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
||||
|
|
|
|||
3
Makefile
3
Makefile
|
|
@ -1,7 +1,7 @@
|
|||
VERSION = 2
|
||||
PATCHLEVEL = 6
|
||||
SUBLEVEL = 32
|
||||
EXTRAVERSION = -rc8
|
||||
EXTRAVERSION =
|
||||
NAME = Man-Eating Seals of Antiquity
|
||||
|
||||
# *DOCUMENTATION*
|
||||
|
|
@ -379,6 +379,7 @@ export RCS_TAR_IGNORE := --exclude SCCS --exclude BitKeeper --exclude .svn --exc
|
|||
PHONY += scripts_basic
|
||||
scripts_basic:
|
||||
$(Q)$(MAKE) $(build)=scripts/basic
|
||||
$(Q)rm -f .tmp_quiet_recordmcount
|
||||
|
||||
# To avoid any implicit rule to kick in, define an empty command.
|
||||
scripts/basic/%: scripts_basic ;
|
||||
|
|
|
|||
16
arch/Kconfig
16
arch/Kconfig
|
|
@ -83,6 +83,13 @@ config KRETPROBES
|
|||
def_bool y
|
||||
depends on KPROBES && HAVE_KRETPROBES
|
||||
|
||||
config USER_RETURN_NOTIFIER
|
||||
bool
|
||||
depends on HAVE_USER_RETURN_NOTIFIER
|
||||
help
|
||||
Provide a kernel-internal notification when a cpu is about to
|
||||
switch to user mode.
|
||||
|
||||
config HAVE_IOREMAP_PROT
|
||||
bool
|
||||
|
||||
|
|
@ -126,4 +133,13 @@ config HAVE_DMA_API_DEBUG
|
|||
config HAVE_DEFAULT_NO_SPIN_MUTEXES
|
||||
bool
|
||||
|
||||
config HAVE_HW_BREAKPOINT
|
||||
bool
|
||||
depends on HAVE_PERF_EVENTS
|
||||
select ANON_INODES
|
||||
select PERF_EVENTS
|
||||
|
||||
config HAVE_USER_RETURN_NOTIFIER
|
||||
bool
|
||||
|
||||
source "kernel/gcov/Kconfig"
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@
|
|||
#define flush_cache_dup_mm(mm) do { } while (0)
|
||||
#define flush_cache_range(vma, start, end) do { } while (0)
|
||||
#define flush_cache_page(vma, vmaddr, pfn) do { } while (0)
|
||||
#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 0
|
||||
#define flush_dcache_page(page) do { } while (0)
|
||||
#define flush_dcache_mmap_lock(mapping) do { } while (0)
|
||||
#define flush_dcache_mmap_unlock(mapping) do { } while (0)
|
||||
|
|
|
|||
|
|
@ -67,6 +67,8 @@
|
|||
#define SO_TIMESTAMPING 37
|
||||
#define SCM_TIMESTAMPING SO_TIMESTAMPING
|
||||
|
||||
#define SO_RXQ_OVFL 40
|
||||
|
||||
/* O_NONBLOCK clashes with the bits used for socket types. Therefore we
|
||||
* have to define SOCK_NONBLOCK to a different value here.
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -61,21 +61,24 @@ register struct thread_info *__current_thread_info __asm__("$8");
|
|||
/*
|
||||
* Thread information flags:
|
||||
* - these are process state flags and used from assembly
|
||||
* - pending work-to-be-done flags come first to fit in and immediate operand.
|
||||
* - pending work-to-be-done flags come first and must be assigned to be
|
||||
* within bits 0 to 7 to fit in and immediate operand.
|
||||
* - ALPHA_UAC_SHIFT below must be kept consistent with the unaligned
|
||||
* control flags.
|
||||
*
|
||||
* TIF_SYSCALL_TRACE is known to be 0 via blbs.
|
||||
*/
|
||||
#define TIF_SYSCALL_TRACE 0 /* syscall trace active */
|
||||
#define TIF_SIGPENDING 1 /* signal pending */
|
||||
#define TIF_NEED_RESCHED 2 /* rescheduling necessary */
|
||||
#define TIF_POLLING_NRFLAG 3 /* poll_idle is polling NEED_RESCHED */
|
||||
#define TIF_DIE_IF_KERNEL 4 /* dik recursion lock */
|
||||
#define TIF_UAC_NOPRINT 5 /* see sysinfo.h */
|
||||
#define TIF_UAC_NOFIX 6
|
||||
#define TIF_UAC_SIGBUS 7
|
||||
#define TIF_MEMDIE 8
|
||||
#define TIF_RESTORE_SIGMASK 9 /* restore signal mask in do_signal */
|
||||
#define TIF_NOTIFY_RESUME 10 /* callback before returning to user */
|
||||
#define TIF_NOTIFY_RESUME 1 /* callback before returning to user */
|
||||
#define TIF_SIGPENDING 2 /* signal pending */
|
||||
#define TIF_NEED_RESCHED 3 /* rescheduling necessary */
|
||||
#define TIF_POLLING_NRFLAG 8 /* poll_idle is polling NEED_RESCHED */
|
||||
#define TIF_DIE_IF_KERNEL 9 /* dik recursion lock */
|
||||
#define TIF_UAC_NOPRINT 10 /* see sysinfo.h */
|
||||
#define TIF_UAC_NOFIX 11
|
||||
#define TIF_UAC_SIGBUS 12
|
||||
#define TIF_MEMDIE 13
|
||||
#define TIF_RESTORE_SIGMASK 14 /* restore signal mask in do_signal */
|
||||
#define TIF_FREEZE 16 /* is freezing for suspend */
|
||||
|
||||
#define _TIF_SYSCALL_TRACE (1<<TIF_SYSCALL_TRACE)
|
||||
|
|
@ -94,7 +97,7 @@ register struct thread_info *__current_thread_info __asm__("$8");
|
|||
#define _TIF_ALLWORK_MASK (_TIF_WORK_MASK \
|
||||
| _TIF_SYSCALL_TRACE)
|
||||
|
||||
#define ALPHA_UAC_SHIFT 6
|
||||
#define ALPHA_UAC_SHIFT 10
|
||||
#define ALPHA_UAC_MASK (1 << TIF_UAC_NOPRINT | 1 << TIF_UAC_NOFIX | \
|
||||
1 << TIF_UAC_SIGBUS)
|
||||
|
||||
|
|
|
|||
|
|
@ -433,10 +433,11 @@
|
|||
#define __NR_signalfd 476
|
||||
#define __NR_timerfd 477
|
||||
#define __NR_eventfd 478
|
||||
#define __NR_recvmmsg 479
|
||||
|
||||
#ifdef __KERNEL__
|
||||
|
||||
#define NR_SYSCALLS 479
|
||||
#define NR_SYSCALLS 480
|
||||
|
||||
#define __ARCH_WANT_IPC_PARSE_VERSION
|
||||
#define __ARCH_WANT_OLD_READDIR
|
||||
|
|
|
|||
|
|
@ -1103,6 +1103,8 @@ marvel_agp_info(void)
|
|||
* Allocate the info structure.
|
||||
*/
|
||||
agp = kmalloc(sizeof(*agp), GFP_KERNEL);
|
||||
if (!agp)
|
||||
return NULL;
|
||||
|
||||
/*
|
||||
* Fill it in.
|
||||
|
|
|
|||
|
|
@ -757,6 +757,8 @@ titan_agp_info(void)
|
|||
* Allocate the info structure.
|
||||
*/
|
||||
agp = kmalloc(sizeof(*agp), GFP_KERNEL);
|
||||
if (!agp)
|
||||
return NULL;
|
||||
|
||||
/*
|
||||
* Fill it in.
|
||||
|
|
|
|||
|
|
@ -92,7 +92,7 @@ show_interrupts(struct seq_file *p, void *v)
|
|||
for_each_online_cpu(j)
|
||||
seq_printf(p, "%10u ", kstat_irqs_cpu(irq, j));
|
||||
#endif
|
||||
seq_printf(p, " %14s", irq_desc[irq].chip->typename);
|
||||
seq_printf(p, " %14s", irq_desc[irq].chip->name);
|
||||
seq_printf(p, " %c%s",
|
||||
(action->flags & IRQF_DISABLED)?'+':' ',
|
||||
action->name);
|
||||
|
|
|
|||
|
|
@ -228,7 +228,7 @@ struct irqaction timer_irqaction = {
|
|||
};
|
||||
|
||||
static struct irq_chip rtc_irq_type = {
|
||||
.typename = "RTC",
|
||||
.name = "RTC",
|
||||
.startup = rtc_startup,
|
||||
.shutdown = rtc_enable_disable,
|
||||
.enable = rtc_enable_disable,
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ i8259a_end_irq(unsigned int irq)
|
|||
}
|
||||
|
||||
struct irq_chip i8259a_irq_type = {
|
||||
.typename = "XT-PIC",
|
||||
.name = "XT-PIC",
|
||||
.startup = i8259a_startup_irq,
|
||||
.shutdown = i8259a_disable_irq,
|
||||
.enable = i8259a_enable_irq,
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue