date:20071217

[PATCH] net/dccp/: Spelling fixes

2007-12-17 Thread Joe Perches


Signed-off-by: Joe Perches [EMAIL PROTECTED]
---
 net/dccp/ackvec.h  |2 +-
 net/dccp/ccids/ccid3.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/dccp/ackvec.h b/net/dccp/ackvec.h
index 9ef0737..9671ecd 100644
--- a/net/dccp/ackvec.h
+++ b/net/dccp/ackvec.h
@@ -71,7 +71,7 @@ struct dccp_ackvec {
  * @dccpavr_ack_ackno - sequence number being acknowledged
  * @dccpavr_ack_ptr - pointer into dccpav_buf where this record starts
  * @dccpavr_ack_nonce - dccpav_ack_nonce at the time this record was sent
- * @dccpavr_sent_len - lenght of the record in dccpav_buf
+ * @dccpavr_sent_len - length of the record in dccpav_buf
  */
 struct dccp_ackvec_record {
struct list_head dccpavr_node;
diff --git a/net/dccp/ccids/ccid3.c b/net/dccp/ccids/ccid3.c
index 19b3358..d133416 100644
--- a/net/dccp/ccids/ccid3.c
+++ b/net/dccp/ccids/ccid3.c
@@ -239,7 +239,7 @@ static void ccid3_hc_tx_no_feedback_timer(unsigned long 
data)
   ccid3_tx_state_name(hctx-ccid3hctx_state),
   (unsigned)(hctx-ccid3hctx_x  6));
/* The value of R is still undefined and so we can not recompute
-* the timout value. Keep initial value as per [RFC 4342, 5]. */
+* the timeout value. Keep initial value as per [RFC 4342, 5]. 
*/
t_nfb = TFRC_INITIAL_TIMEOUT;
ccid3_update_send_interval(hctx);
break;
-- 
1.5.3.7.949.g2221a6

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] net/ipv6/: Spelling fixes

2007-12-17 Thread Joe Perches


Signed-off-by: Joe Perches [EMAIL PROTECTED]
---
 net/ipv6/ndisc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 67997a7..777ed73 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -612,7 +612,7 @@ void ndisc_send_rs(struct net_device *dev, struct in6_addr 
*saddr,
 * optimistic addresses, but we may send the solicitation
 * if we don't include the sllao.  So here we check
 * if our address is optimistic, and if so, we
-* supress the inclusion of the sllao.
+* suppress the inclusion of the sllao.
 */
if (send_sllao) {
struct inet6_ifaddr *ifp = ipv6_get_ifaddr(saddr, dev, 1);
-- 
1.5.3.7.949.g2221a6

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] sound/: Spelling fixes

2007-12-17 Thread Joe Perches


Signed-off-by: Joe Perches [EMAIL PROTECTED]
---
 sound/drivers/serial-u16550.c|6 ++--
 sound/isa/es18xx.c   |2 +-
 sound/pci/au88x0/au88x0_core.c   |2 +-
 sound/pci/cs46xx/cs46xx_lib.c|2 +-
 sound/pci/hda/hda_codec.h|2 +-
 sound/pci/rme9652/hdsp.c |2 +-
 sound/pci/rme9652/hdspm.c|4 +-
 sound/pci/rme9652/rme9652.c  |4 +-
 sound/pci/trident/trident_main.c |   44 +++---
 9 files changed, 34 insertions(+), 34 deletions(-)

diff --git a/sound/drivers/serial-u16550.c b/sound/drivers/serial-u16550.c
index 65de3a7..3958dbd 100644
--- a/sound/drivers/serial-u16550.c
+++ b/sound/drivers/serial-u16550.c
@@ -455,7 +455,7 @@ static void snd_uart16550_do_open(struct snd_uart16550 * 
uart)
| UART_IER_THRI /* Enable Transmitter holding register 
empty interrupt */
;
}
-   outb(byte, uart-base + UART_IER);  /* Interupt enable Register */
+   outb(byte, uart-base + UART_IER);  /* Interrupt enable Register */
 
inb(uart-base + UART_LSR); /* Clear any pre-existing overrun 
indication */
inb(uart-base + UART_IIR); /* Clear any pre-existing transmit 
interrupt */
@@ -473,7 +473,7 @@ static void snd_uart16550_do_close(struct snd_uart16550 * 
uart)
 
outb((0  UART_IER_RDI) /* Disable Receiver data interrupt */
 |(0  UART_IER_THRI)   /* Disable Transmitter holding register 
empty interrupt */
-,uart-base + UART_IER);   /* Interupt enable Register */
+,uart-base + UART_IER);   /* Interrupt enable Register */
 
switch (uart-adaptor) {
default:
@@ -653,7 +653,7 @@ static void snd_uart16550_output_write(struct 
snd_rawmidi_substream *substream)
char first;
static unsigned long lasttime = 0;

-   /* Interupts are disabled during the updating of the tx_buff,
+   /* Interrupts are disabled during the updating of the tx_buff,
 * since it is 'bad' to have two processes updating the same
 * variables (ie buff_in  buff_out)
 */
diff --git a/sound/isa/es18xx.c b/sound/isa/es18xx.c
index c1af28f..5f927ad 100644
--- a/sound/isa/es18xx.c
+++ b/sound/isa/es18xx.c
@@ -163,7 +163,7 @@ struct snd_audiodrive {
 #define ES18XX_DUPLEX_SAME 0x0010  /* Playback and record must share the 
same rate */
 #define ES18XX_NEW_RATE0x0020  /* More precise rate setting */
 #define ES18XX_AUXB0x0040  /* AuxB mixer control */
-#define ES18XX_HWV 0x0080  /* Has seperate hardware volume mixer controls*/
+#define ES18XX_HWV 0x0080  /* Has separate hardware volume mixer controls*/
 #define ES18XX_MONO0x0100  /* Mono_in mixer control */
 #define ES18XX_I2S 0x0200  /* I2S mixer control */
 #define ES18XX_MUTEREC 0x0400  /* Record source can be muted */
diff --git a/sound/pci/au88x0/au88x0_core.c b/sound/pci/au88x0/au88x0_core.c
index 4a336ea..333c62d 100644
--- a/sound/pci/au88x0/au88x0_core.c
+++ b/sound/pci/au88x0/au88x0_core.c
@@ -2395,7 +2395,7 @@ static irqreturn_t vortex_interrupt(int irq, void *dev_id)
if (!(hwread(vortex-mmio, VORTEX_STAT)  0x1))
return IRQ_NONE;
 
-   // This is the Interrrupt Enable flag we set before (consistency check).
+   // This is the Interrupt Enable flag we set before (consistency check).
if (!(hwread(vortex-mmio, VORTEX_CTRL)  CTRL_IRQ_ENABLE))
return IRQ_NONE;
 
diff --git a/sound/pci/cs46xx/cs46xx_lib.c b/sound/pci/cs46xx/cs46xx_lib.c
index 2c7bfc9..c004fa8 100644
--- a/sound/pci/cs46xx/cs46xx_lib.c
+++ b/sound/pci/cs46xx/cs46xx_lib.c
@@ -8,7 +8,7 @@
  *- Sometimes the SPDIF input DSP tasks get's unsynchronized
  *  and the SPDIF get somewhat distorcionated, or/and left right channel
  *  are swapped. To get around this problem when it happens, mute and 
unmute 
- *  the SPDIF input mixer controll.
+ *  the SPDIF input mixer control.
  *- On the Hercules Game Theater XP the amplifier are sometimes turned
  *  off on inadecuate moments which causes distorcions on sound.
  *
diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h
index 2bce925..5bd44ac 100644
--- a/sound/pci/hda/hda_codec.h
+++ b/sound/pci/hda/hda_codec.h
@@ -417,7 +417,7 @@ struct hda_bus_ops {
/* free the private data */
void (*private_free)(struct hda_bus *);
 #ifdef CONFIG_SND_HDA_POWER_SAVE
-   /* notify power-up/down from codec to contoller */
+   /* notify power-up/down from codec to controller */
void (*pm_notify)(struct hda_codec *codec);
 #endif
 };
diff --git a/sound/pci/rme9652/hdsp.c b/sound/pci/rme9652/hdsp.c
index ff26a36..263cd16 100644
--- a/sound/pci/rme9652/hdsp.c
+++ b/sound/pci/rme9652/hdsp.c
@@ -3606,7 +3606,7 @@ static int snd_hdsp_set_defaults(struct hdsp *hdsp)
 
/* ASSUMPTION: hdsp-lock is either held, or
   there is no need to hold it (e.g.

[PATCH] include/sound/: Spelling fixes

2007-12-17 Thread Joe Perches


Signed-off-by: Joe Perches [EMAIL PROTECTED]
---
 include/sound/ad1848.h  |2 +-
 include/sound/cs4231-regs.h |2 +-
 include/sound/soc-dapm.h|2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/sound/ad1848.h b/include/sound/ad1848.h
index d04f9e7..d9aebdf 100644
--- a/include/sound/ad1848.h
+++ b/include/sound/ad1848.h
@@ -48,7 +48,7 @@
 #define AD1848_IFACE_CTRL  0x09/* interface control - bits 7-2 MCE */
 #define AD1848_PIN_CTRL0x0a/* pin control */
 #define AD1848_TEST_INIT   0x0b/* test and initialization */
-#define AD1848_MISC_INFO   0x0c/* miscellaneaous information */
+#define AD1848_MISC_INFO   0x0c/* miscellaneous information */
 #define AD1848_LOOPBACK0x0d/* loopback control */
 #define AD1848_DATA_UPR_CNT0x0e/* playback/capture upper base count */
 #define AD1848_DATA_LWR_CNT0x0f/* playback/capture lower base count */
diff --git a/include/sound/cs4231-regs.h b/include/sound/cs4231-regs.h
index f149026..e8d1f3e 100644
--- a/include/sound/cs4231-regs.h
+++ b/include/sound/cs4231-regs.h
@@ -45,7 +45,7 @@
 #define CS4231_IFACE_CTRL  0x09/* interface control - bits 7-2 MCE */
 #define CS4231_PIN_CTRL0x0a/* pin control */
 #define CS4231_TEST_INIT   0x0b/* test and initialization */
-#define CS4231_MISC_INFO   0x0c/* miscellaneaous information */
+#define CS4231_MISC_INFO   0x0c/* miscellaneous information */
 #define CS4231_LOOPBACK0x0d/* loopback control */
 #define CS4231_PLY_UPR_CNT 0x0e/* playback upper base count */
 #define CS4231_PLY_LWR_CNT 0x0f/* playback lower base count */
diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h
index 2b1ae8e..b9d5864 100644
--- a/include/sound/soc-dapm.h
+++ b/include/sound/soc-dapm.h
@@ -22,7 +22,7 @@
 #define SND_SOC_NOPM   -1
 
 /*
- * SoC dynamic audio power managment
+ * SoC dynamic audio power management
  *
  * We can have upto 4 power domains
  * 1. Codec domain - VREF, VMID
-- 
1.5.3.7.949.g2221a6

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] net/sctp/: Spelling fixes

2007-12-17 Thread Joe Perches


Signed-off-by: Joe Perches [EMAIL PROTECTED]
---
 net/sctp/sm_make_chunk.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index f487629..ed7c9e3 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -286,7 +286,7 @@ struct sctp_chunk *sctp_make_init(const struct 
sctp_association *asoc,
 
sctp_addto_chunk(retval, sizeof(ecap_param), ecap_param);
 
-   /* Add the supported extensions paramter.  Be nice and add this
+   /* Add the supported extensions parameter.  Be nice and add this
 * fist before addiding the parameters for the extensions themselves
 */
if (num_ext) {
@@ -2859,7 +2859,7 @@ struct sctp_chunk *sctp_process_asconf(struct 
sctp_association *asoc,
chunk_len -= length;
 
/* Skip the address parameter and store a pointer to the first
-* asconf paramter.
+* asconf parameter.
 */
length = ntohs(addr_param-v4.param_hdr.length);
asconf_param = (sctp_addip_param_t *)((void *)addr_param + length);
@@ -2868,7 +2868,7 @@ struct sctp_chunk *sctp_process_asconf(struct 
sctp_association *asoc,
/* create an ASCONF_ACK chunk.
 * Based on the definitions of parameters, we know that the size of
 * ASCONF_ACK parameters are less than or equal to the twice of ASCONF
-* paramters.
+* parameters.
 */
asconf_ack = sctp_make_asconf_ack(asoc, serial, chunk_len * 2);
if (!asconf_ack)
@@ -3062,7 +3062,7 @@ int sctp_process_asconf_ack(struct sctp_association *asoc,
asconf_len -= length;
 
/* Skip the address parameter in the last asconf sent and store a
-* pointer to the first asconf paramter.
+* pointer to the first asconf parameter.
 */
length = ntohs(addr_param-v4.param_hdr.length);
asconf_param = (sctp_addip_param_t *)((void *)addr_param + length);
-- 
1.5.3.7.949.g2221a6

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] net/sched/: Spelling fixes

2007-12-17 Thread Joe Perches


Signed-off-by: Joe Perches [EMAIL PROTECTED]
---
 net/sched/sch_hfsc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/sched/sch_hfsc.c b/net/sched/sch_hfsc.c
index 55e7e45..a6ad491 100644
--- a/net/sched/sch_hfsc.c
+++ b/net/sched/sch_hfsc.c
@@ -160,7 +160,7 @@ struct hfsc_class
u64 cl_vtoff;   /* inter-period cumulative vt offset */
u64 cl_cvtmax;  /* max child's vt in the last period */
u64 cl_cvtoff;  /* cumulative cvtmax of all periods */
-   u64 cl_pcvtoff; /* parent's cvtoff at initalization
+   u64 cl_pcvtoff; /* parent's cvtoff at initialization
   time */
 
struct internal_sc cl_rsc;  /* internal real-time service curve */
-- 
1.5.3.7.949.g2221a6

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] net/netlabel/: Spelling fixes

2007-12-17 Thread Joe Perches


Signed-off-by: Joe Perches [EMAIL PROTECTED]
---
 net/netlabel/netlabel_mgmt.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/netlabel/netlabel_mgmt.c b/net/netlabel/netlabel_mgmt.c
index 5648337..9c41464 100644
--- a/net/netlabel/netlabel_mgmt.c
+++ b/net/netlabel/netlabel_mgmt.c
@@ -71,7 +71,7 @@ static const struct nla_policy 
netlbl_mgmt_genl_policy[NLBL_MGMT_A_MAX + 1] = {
 };
 
 /*
- * NetLabel Misc Managment Functions
+ * NetLabel Misc Management Functions
  */
 
 /**
-- 
1.5.3.7.949.g2221a6

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] net/irda/: Spelling fixes

2007-12-17 Thread Joe Perches


Signed-off-by: Joe Perches [EMAIL PROTECTED]
---
 net/irda/ircomm/ircomm_param.c |2 +-
 net/irda/irlan/irlan_eth.c |2 +-
 net/irda/irlap_frame.c |2 +-
 net/irda/parameters.c  |   12 ++--
 net/irda/wrapper.c |2 +-
 5 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/net/irda/ircomm/ircomm_param.c b/net/irda/ircomm/ircomm_param.c
index e5e4792..598dcbe 100644
--- a/net/irda/ircomm/ircomm_param.c
+++ b/net/irda/ircomm/ircomm_param.c
@@ -496,7 +496,7 @@ static int ircomm_param_poll(void *instance, irda_param_t 
*param, int get)
IRDA_ASSERT(self != NULL, return -1;);
IRDA_ASSERT(self-magic == IRCOMM_TTY_MAGIC, return -1;);
 
-   /* Poll parameters are always of lenght 0 (just a signal) */
+   /* Poll parameters are always of length 0 (just a signal) */
if (!get) {
/* Respond with DTE line settings */
ircomm_param_request(self, IRCOMM_DTE, TRUE);
diff --git a/net/irda/irlan/irlan_eth.c b/net/irda/irlan/irlan_eth.c
index c682207..1ab91f7 100644
--- a/net/irda/irlan/irlan_eth.c
+++ b/net/irda/irlan/irlan_eth.c
@@ -342,7 +342,7 @@ static void irlan_eth_set_multicast_list(struct net_device 
*dev)
 
if (dev-flags  IFF_PROMISC) {
/* Enable promiscuous mode */
-   IRDA_WARNING(Promiscous mode not implemented by IrLAN!\n);
+   IRDA_WARNING(Promiscuous mode not implemented by IrLAN!\n);
}
else if ((dev-flags  IFF_ALLMULTI) || dev-mc_count  HW_MAX_ADDRS) {
/* Disable promiscuous mode, use normal mode. */
diff --git a/net/irda/irlap_frame.c b/net/irda/irlap_frame.c
index 4f37645..7c132d6 100644
--- a/net/irda/irlap_frame.c
+++ b/net/irda/irlap_frame.c
@@ -144,7 +144,7 @@ void irlap_send_snrm_frame(struct irlap_cb *self, struct 
qos_info *qos)
frame-control = SNRM_CMD | PF_BIT;
 
/*
-*  If we are establishing a connection then insert QoS paramerters
+*  If we are establishing a connection then insert QoS parameters
 */
if (qos) {
skb_put(tx_skb, 9); /* 25 left */
diff --git a/net/irda/parameters.c b/net/irda/parameters.c
index 2627dad..b23a3c7 100644
--- a/net/irda/parameters.c
+++ b/net/irda/parameters.c
@@ -133,7 +133,7 @@ static int irda_insert_integer(void *self, __u8 *buf, int 
len, __u8 pi,
int err;
 
p.pi = pi; /* In case handler needs to know */
-   p.pl = type  PV_MASK; /* The integer type codes the lenght as well */
+   p.pl = type  PV_MASK; /* The integer type codes the length as well */
p.pv.i = 0;/* Clear value */
 
/* Call handler for this parameter */
@@ -142,7 +142,7 @@ static int irda_insert_integer(void *self, __u8 *buf, int 
len, __u8 pi,
return err;
 
/*
-* If parameter lenght is still 0, then (1) this is an any length
+* If parameter length is still 0, then (1) this is an any length
 * integer, and (2) the handler function does not care which length
 * we choose to use, so we pick the one the gives the fewest bytes.
 */
@@ -206,11 +206,11 @@ static int irda_extract_integer(void *self, __u8 *buf, 
int len, __u8 pi,
 {
irda_param_t p;
int n = 0;
-   int extract_len;/* Real lenght we extract */
+   int extract_len;/* Real length we extract */
int err;
 
p.pi = pi; /* In case handler needs to know */
-   p.pl = buf[1]; /* Extract lenght of value */
+   p.pl = buf[1]; /* Extract length of value */
p.pv.i = 0;/* Clear value */
extract_len = p.pl; /* Default : extract all */
 
@@ -297,7 +297,7 @@ static int irda_extract_string(void *self, __u8 *buf, int 
len, __u8 pi,
IRDA_DEBUG(2, %s()\n, __FUNCTION__);
 
p.pi = pi; /* In case handler needs to know */
-   p.pl = buf[1]; /* Extract lenght of value */
+   p.pl = buf[1]; /* Extract length of value */
 
IRDA_DEBUG(2, %s(), pi=%#x, pl=%d\n, __FUNCTION__,
   p.pi, p.pl);
@@ -339,7 +339,7 @@ static int irda_extract_octseq(void *self, __u8 *buf, int 
len, __u8 pi,
irda_param_t p;
 
p.pi = pi; /* In case handler needs to know */
-   p.pl = buf[1]; /* Extract lenght of value */
+   p.pl = buf[1]; /* Extract length of value */
 
/* Check if buffer is long enough for parsing */
if (len  (2+p.pl)) {
diff --git a/net/irda/wrapper.c b/net/irda/wrapper.c
index e712867..c246983 100644
--- a/net/irda/wrapper.c
+++ b/net/irda/wrapper.c
@@ -238,7 +238,7 @@ async_bump(struct net_device *dev,
skb_reserve(newskb, 1);
 
if(docopy) {
-   /* Copy data without CRC (lenght already checked) */
+   /* Copy data without CRC (length already checked) */
skb_copy_to_linear_data(newskb, rx_buff-data,
rx_buff-len -

[PATCH] net/netfilter/: Spelling fixes

2007-12-17 Thread Joe Perches


Signed-off-by: Joe Perches [EMAIL PROTECTED]
---
 net/netfilter/nf_conntrack_sip.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/netfilter/nf_conntrack_sip.c b/net/netfilter/nf_conntrack_sip.c
index 8f8b5a4..515abff 100644
--- a/net/netfilter/nf_conntrack_sip.c
+++ b/net/netfilter/nf_conntrack_sip.c
@@ -187,7 +187,7 @@ static const struct sip_header_nfo ct_sip_hdrs[] = {
}
 };
 
-/* get line lenght until first CR or LF seen. */
+/* get line length until first CR or LF seen. */
 int ct_sip_lnlen(const char *line, const char *limit)
 {
const char *k = line;
@@ -236,7 +236,7 @@ static int digits_len(struct nf_conn *ct, const char *dptr,
return len;
 }
 
-/* get digits lenght, skiping blank spaces. */
+/* get digits length, skipping blank spaces. */
 static int skp_digits_len(struct nf_conn *ct, const char *dptr,
  const char *limit, int *shift)
 {
-- 
1.5.3.7.949.g2221a6

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arch/powerpc/: Spelling fixes

2007-12-17 Thread Josh Boyer

On Mon, 17 Dec 2007 11:30:12 -0800
Joe Perches [EMAIL PROTECTED] wrote:

 
 Signed-off-by: Joe Perches [EMAIL PROTECTED]
 ---
  arch/powerpc/boot/4xx.c |2 +-
  arch/powerpc/kernel/legacy_serial.c |2 +-
  arch/powerpc/sysdev/bestcomm/bestcomm.h |2 +-
  arch/powerpc/sysdev/mmio_nvram.c|2 +-
  4 files changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/arch/powerpc/boot/4xx.c b/arch/powerpc/boot/4xx.c
 index ebf9e21..3d0e4f9 100644
 --- a/arch/powerpc/boot/4xx.c
 +++ b/arch/powerpc/boot/4xx.c
 @@ -122,7 +122,7 @@ void ibm4xx_denali_fixup_memsize(void)
   else
   dpath = 4; /* 32 bits */
 
 - /* get adress pins (rows) */
 + /* get address pins (rows) */
   val = mfdcr_sdram0(DDR0_42);
 
   row = DDR_GET_VAL(val, DDR_APIN, DDR_APIN_SHIFT);

Ack on this part.

josh
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] [UDP6]: Counter increment on BH mode

2007-12-17 Thread Christoph Lameter

On Sun, 16 Dec 2007, Herbert Xu wrote:

 If we can get the address of the per-cpu counter against
 some sort of a per-cpu base pointer, e.g., %gs on x86, then
 we can do
 
   incq%gs:(%rax)
 
 where %rax would be the offset with %gs as the base.  This would
 obviate the need for the CPU ID and therefore avoid disabling
 preemption.
 
 Hmm, wasn't Christoph working on something like that?

Yes that is what the cpu alloc patchset implements.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] net/ipv4/: Spelling fixes

2007-12-17 Thread Joe Perches


Signed-off-by: Joe Perches [EMAIL PROTECTED]
---
 net/ipv4/netfilter/nf_nat_sip.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/ipv4/netfilter/nf_nat_sip.c b/net/ipv4/netfilter/nf_nat_sip.c
index 3ca9897..8996ccb 100644
--- a/net/ipv4/netfilter/nf_nat_sip.c
+++ b/net/ipv4/netfilter/nf_nat_sip.c
@@ -165,7 +165,7 @@ static int mangle_content_len(struct sk_buff *skb,
 
dataoff = ip_hdrlen(skb) + sizeof(struct udphdr);
 
-   /* Get actual SDP lenght */
+   /* Get actual SDP length */
if (ct_sip_get_info(ct, dptr, skb-len - dataoff, matchoff,
matchlen, POS_SDP_HEADER)  0) {
 
-- 
1.5.3.7.949.g2221a6

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

2007-12-17 Thread David P. Reed


H. Peter Anvin wrote:

Rene Herman wrote:


I do not know how universal that is, but _reading_ port 0xf0 might in 
fact be sensible then? And should even work on a 386/387 pair? (I 
have a 386/387 in fact, although I'd need to dig it up).




No.  Someone might have used 0xf0 as a readonly port for other uses.

As support: port 80 on the reporter's (my) HP dv9000z laptop clearly 
responds to reads differently than unused ports.  In particular, an 
inb takes 1/2 the elapsed time compared to a read to known unused port 
0xed - 792 tsc ticks for port 80 compared to about 1450 tsc ticks for 
port 0xed and other unused ports (tsc at 800 MHz).


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: almost daily Kernel oops with 2.6.23.9 - and now 2.6.23.11 as well

2007-12-17 Thread Hemmann, Volker Armin

On Montag, 17. Dezember 2007, you wrote:
 On Mon, 17 Dec 2007, Hemmann, Volker Armin wrote:
  I got another crash, now with 2.6.23.11 on logout from KDE (two
  differences, new kernel, 4gb ram instead of 2gb):

  also I got some strange message yesterday before increasing ramsize:
  [19546.639528] swap_free: Bad swap offset entry 0400
  [27999.370777] swap_free: Bad swap offset entry 0400
  [27999.434282] swap_free: Bad swap offset entry 0400
  [27999.466035] swap_free: Bad swap offset entry 0400
  [27999.521132] swap_free: Bad swap offset entry 0400
  [27999.561621] VM: killing process ld-linux-x86-64
  [27999.561719] swap_free: Bad swap offset entry 0400

 You're seeing a single bit set where it shouldn't be: please give
 memtest86+ a good try; if it's not actually your memory that's bad,
 then I'd guess it's something like overheating (please correct me,
 ye who know better).

 Hugh

first of all, the 2 with which I was seeing that have had their memtest run 
for some hours some weeks ago, without problems. I can compile stuff - like 
the latest kde4 rc without segfaults or problems (except when the oops is 
happening), and this mess only started recently. To be more correct:
the swap-mess only started with 2.6.23.11. With 2.6.23.9 I get the kio_http... 
rip's, but no swap related messages.

Overheating is very unlikely. I made sure that my computer is very well 
cooled. Even under high load I get something like 50°C from lmsensors and 
bios - and the errors are completly unrelated to load. Or temperature. 
Without load my cpu idles at ~30°C. Again, lmsensors and bios are very close 
about that.

Glück Auf,
Volker
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

2007-12-17 Thread Serge E. Hallyn

Quoting Tetsuo Handa ([EMAIL PROTECTED]):
 A brief description about SYAORAN:
 
  SYAORAN stands for Simple Yet All-important Object Realizing Abiding
  Nexus. SYAORAN is a filesystem for /dev with Mandatory Access Control.
 
  /dev needs to be writable, but this means that files on /dev might be
  tampered with. SYAORAN can restrict combinations of (pathname, attribute)
  that the system can create. The attribute is one of directory, regular
  file, FIFO, UNIX domain socket, symbolic link, character or block device
  file with major/minor device numbers.
 
  SYAORAN can ensure /dev/null is a character device file with major=1 minor=3.
 
  Policy specifications for this filesystem is at
  http://tomoyo.sourceforge.jp/en/1.5.x/policy-syaoran.html
 
 Why not use FUSE?
 
  Because /dev has to be available through the lifetime of the kernel.
  It is not acceptable if /dev stops working due to SIGKILL or OOM-killer.
 
 Why not use SELinux?
 
  Because SELinux doesn't guarantee filename and its attribute.
  The purpose of this filesystem is to ensure filename and its attribute
  (e.g. /dev/null is guaranteed to be a character device file
  with major=1 and minor=3).

We need something similar for system containers (like vservers).  We
will likely want root in a container to be confined to a certain set
of devices.

For starters we expect to use the capability bounding sets (see
http://lkml.org/lkml/2007/11/26/206).  So a container will have a static
/dev predefined, and CAP_MKNOD will be removed from its capability
bounding set so that root in a container cannot create any more new
devices.

For future more sophisticated device controls, two similar approaches
have been suggested (one by me, see
https://lists.linux-foundation.org/pipermail/containers/2007-September/007423.html
and
https://lists.linux-foundation.org/pipermail/containers/2007-November/008589.html
).  Both actually control the devices a process can create period,
rather than trying to control at the filesystem.  And yes, these both
lack the feature in your solution that for instance 'c 1 3' must be
called null, which appears to be the kind of guarantee apparmor likes to
provide.

To use your approach, i guess we would have to use selinux (or tomoyo)
to enforce that devices may only be created under /dev?

-serge
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ip neigh show not showing arp cache entries?

2007-12-17 Thread Chris Friesen


Patrick McHardy wrote:


 From a kernel perspective there are only complete dumps, the
filtering is done by iproute. So the fact that it shows them
when querying specifically implies there is a bug in the
iproute neighbour filter. Does it work if you omit all
from the ip neigh show command?


Omitting all gives identical results.  It is still missing entries 
when compared with the output of arp.


Chris
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Uclinux-dist-devel] [PATCH] arch/blackfin/: Spelling fixes

2007-12-17 Thread Mike Frysinger

On Dec 17, 2007 2:30 PM, Joe Perches [EMAIL PROTECTED] wrote:

 Signed-off-by: Joe Perches [EMAIL PROTECTED]
 ---
  arch/blackfin/kernel/early_printk.c  |2 +-
  arch/blackfin/mach-bf548/ints-priority.c |2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

thanks, this has been merged into the Blackfin tree and will get
pushed by Bryan during the next set
-mike
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net/netlabel/: Spelling fixes

2007-12-17 Thread Paul Moore

On Monday 17 December 2007 2:40:35 pm Joe Perches wrote:
 Signed-off-by: Joe Perches [EMAIL PROTECTED]

Thanks Joe.

Acked-by: Paul Moore [EMAIL PROTECTED]

 ---
  net/netlabel/netlabel_mgmt.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/net/netlabel/netlabel_mgmt.c b/net/netlabel/netlabel_mgmt.c
 index 5648337..9c41464 100644
 --- a/net/netlabel/netlabel_mgmt.c
 +++ b/net/netlabel/netlabel_mgmt.c
 @@ -71,7 +71,7 @@ static const struct nla_policy
 netlbl_mgmt_genl_policy[NLBL_MGMT_A_MAX + 1] = { };

  /*
 - * NetLabel Misc Managment Functions
 + * NetLabel Misc Management Functions
   */

  /**



-- 
paul moore
linux security @ hp
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

problem with ending requests asynchronously in my block device driver

2007-12-17 Thread cable_plug


Hi, 

I've a block device driver which does the following, 

Inside the request function I do something like this: 
request(fn) { 

 while ((req = elv_next_request(q)) != NULL) { 
set up the request; 
 spin_unlock_irq(q-queue_lock); 
call the transfer(set_up_req) function; 
spin_lock_irq(q-queue_lock); 
} 
   spin_unlock_irq (q-queue_lock); 
/* allow callback to execute as it needs the lock!!! */ 
spin_lock_irq (q-queue_lock); 


} 
and the transfer function calls the scsi_execute_asyn() with the
callback function doing the end request. So, the ending of the request is
done like below: 

callback(fn) { 

 spin_lock_irqsave(q-queue_lock, flags); 
if (!end_that_request_first(set_up_req-req, cmpstatus, 
set_up_req-req-nr_sectors)) { 
add_disk_randomness(...); 
end_that_request_last(set_up_req-req,0); 
} 
spin_unlock_irqrestore(q-queue_lock, flags); 
} 


This code works fine with most of the kernel versions, but fails on some
like , Linux 2.6.18-8.el5-xen 

Please help me to find out where I'm going wrong? 

when I say 'fails' it just hangs without any error I'm using dt(Data
test) to write to the disk. The logs show that all the requests that have
been sent for processing, have completed sucessfully. Its just that new
requests never enter the request function. So, the dt writes almost half the
data and then simply hangs. 

  
  The actual code does nothing but, call the scsi_execute_async , which 
 later on calls the callback function which is used to end the request. 
 So, both the callback function and the request function need to share 
 the queue lock. So the code samples I sent cover all the aspects of my 
 program. What I'm looking for here is how can I end the requests 
 asynchronously much later after the request processing is done. Please note 
 here that the asynchronous end requests is done by the callback function 
 of the scsi_execute_async, which needs to share the queue lock with 
 the request function. 

  when I say 'fails' it just hangs without any error I'm using 
 dt(Data 
test) to write to the disk. The logs show that all the requests that 
 have 
been sent for processing, have completed successfully. Its just that new 
requests never enter the request function. So, the dt writes almost 
 half the 
data and then simply hangs. 


Thanks in advance for an early reply. 
Anil P.
-- 
View this message in context: 
http://www.nabble.com/problem-with-ending-requests-asynchronously-in-my-block-device-driver-tp14374016p14374016.html
Sent from the linux-kernel mailing list archive at Nabble.com.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: slab quirks in DEBUG, ctor, and initialization

2007-12-17 Thread Pekka Enberg

Hi John,

On Dec 17, 2007 5:47 PM, John Reiser [EMAIL PROTECTED] wrote:
 In mm/slab.c, the DEBUG variant of cache_alloc_debugcheck_after
 might call  cachep-ctor(objp, cachep, 0);  but the non-DEBUG
 variant does absolutely nothing.  idr_pre_get is a routine
 which notices the difference.

How does ipr_pre_get notice this?

On Dec 17, 2007 5:47 PM, John Reiser [EMAIL PROTECTED] wrote:
 Even when cache_alloc_debugcheck_after does invoke the ctor,
 then it is conditional upon  cachep-flags  SLAB_POISON.  This
 assumes that the only two states are poisoned and all-zero
 (from .bss static, or via a cleared new page frame.)
 So if SLAB_POISON is not specified, then a ctor which
 does anything other than memset(,0,) is out of luck.
 Instead: if a ctor is specified then it should be called
 for each successful allocation.

Sorry, I don't understand at all what's the problem is here. For the
common (non-poison) case, we initialize all objects *once* whenever a
cache is grown (see cache_grow calling cache_init_objs) which is the
whole point of having constructors. When poisoning is enabled, we
obviously cannot do this which is why we call the constructor for
every allocation.

Pekka
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] include/asm-mips/: Spelling fixes

2007-12-17 Thread Sergei Shtylyov


Hello.

Joe Perches wrote:


Signed-off-by: Joe Perches [EMAIL PROTECTED]



diff --git a/include/asm-mips/mach-wrppmc/mach-gt64120.h 
b/include/asm-mips/mach-wrppmc/mach-gt64120.h
index 00d8bf6..465234a 100644
--- a/include/asm-mips/mach-wrppmc/mach-gt64120.h
+++ b/include/asm-mips/mach-wrppmc/mach-gt64120.h
@@ -45,7 +45,7 @@
 #define GT_PCI_IO_SIZE 0x0200UL
 
 /*

- * PCI interrupts will come in on either the INTA or INTD interrups lines,
+ * PCI interrupts will come in on either the INTA or INTD interrupts lines,


   interrupt here.

WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52, [2.6.24-rc4-git5: Reported regressions from 2.6.23]

2007-12-17 Thread Christoph Lameter

On Fri, 14 Dec 2007, Ingo Molnar wrote:

 which is of little help if it regresses on other workloads. As we've 
 seen it, SLUB can be more than 10 times slower on hackbench. You can 
 tune SLUB to use 2MB pages but of course that's not a production level 
 system. OTOH, have you tried to tune SLAB in the above benchmark?

Hackbench is one special use case and I was not aware of there being an 
issue there. AFAICT other workloads are fine. I still do not understand 
why the measures in SLUB to avoid lock contention do not take in this 
case. Need to run some more tests.

  - Single threaded allocation speed is up to double that of SLAB
 
 link?

Same as link as for the earlier numbers.

  - Debugging on SLAB is difficult. Requires recompile of the kernel
and the resulting output is difficult to interpret. SLUB can apply
debugging options to a subset of the slabcaches in order to allow
the system to work with maximum speed. This is necessary to detect
difficult to reproduce race conditions.
 
 that's not a fundamental property of SLAB. It would be an about 10 lines 
 hack to enable SLAB debugging switchable-on runtime, with the boot flag 
 defaulting to 'off'.

Well try it. Note that you need to avoid the runtime debugging result in a 
negative performance impact.
 
  - SLAB can capture huge amounts of memory in its queues. The problem
gets worse the more processors and NUMA nodes are in the system. The 
amount of memory limits the number of per cpu objects one can 
configure.
 
 well that's the nature of caches, but it could be improved: restrict 
 alien caches along cpusets and demand-allocate them.

Maybe but that adds additional complexity. There are other issues with 
queues too.

  - SLAB requires a pass through all slab caches every 2 seconds to
expire objects. This is a problem both for realtime and MPI jobs 
that cannot take such a processor outage.
 
 the moment you start capturing more memory in SLUB's per cpu queues 
 (which do exist), you will have the same sort of problem.

There are no queues and thus no problem in SLUB. The per cpu slab is 
exactly one slab and cannot grow beyond that.

  - SLAB requires the update of two words for freeing
and allocation. SLUB can do that by updating a single word which 
allows to avoid enabling and disabling interrupts if the processor 
supports an atomic instruction for that purpose. This is important 
for realtime kernels where special measures may have to be 
implemented if one wants to disable interrupts.
 
 i do appreciate that :-) SLUB was rather easy to port to PREEMPT_RT: 
 it did not need a single line of change. The SLAB portion is a lot 
 scarier:

Finally something positive. I think we can get to a point where SLUB can 
be the same on RT and non RT. 
 
 How about renaming it to SLAB2 instead of SLUB? The unqueued bit is 
 just stupid NIH syndrome. It's _of course_ queued because it has to. It 
 does not have _THAT_ queue as SLAB used to have is just a silly excuse.

Hmmm yes. At some point I want to remove SLAB and rename SLUB SLAB. Note 
that the queues (if you want to call the per slab page freelist queues) 
are significantly different.

  - SLUB creates rarely used DMA caches on demand instead of creating
them all on bootup (SLAB).
 
 actually, this might be a bug. the DMA caches should be created right 
 away and filled with a small amount of objects due to stupid 16MB 
 limitations with certain hardware. Later on a GFP_DMA request might not 
 be fulfillable. (because that zone is filled up pretty quickly)

Use of SLAB DMA memory are exceedingly rare. Andi Kleen has removed 
almost all uses of slab DMA. The DMA must remain allocatable in order to 
allow allocations for legacy device drivers. If it fills up then we will 
have other issues.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

2007-12-17 Thread H. Peter Anvin


David P. Reed wrote:


Still wondering:

   what the heck is going on with port 80 on my laptop motherboard.  
Clearly it does something.
   I will in my spare time continue investigating, though having a 
reliable system is GREAT.




Almost guaranteed to be some kind of debugging hack, probably 
implemented either in the SuperIO chip or in SMM (or both).  When some 
sort of log buffer fills up, the system dies.


-hpa
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

2007-12-17 Thread H. Peter Anvin


David P. Reed wrote:

H. Peter Anvin wrote:

Rene Herman wrote:


I do not know how universal that is, but _reading_ port 0xf0 might in 
fact be sensible then? And should even work on a 386/387 pair? (I 
have a 386/387 in fact, although I'd need to dig it up).




No.  Someone might have used 0xf0 as a readonly port for other uses.

As support: port 80 on the reporter's (my) HP dv9000z laptop clearly 
responds to reads differently than unused ports.  In particular, an 
inb takes 1/2 the elapsed time compared to a read to known unused port 
0xed - 792 tsc ticks for port 80 compared to about 1450 tsc ticks for 
port 0xed and other unused ports (tsc at 800 MHz).




Any timings for port 0xf0 (write zero), out of curiosity?

-hpa
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] include/asm-arm/: Spelling fixes

2007-12-17 Thread J. Bruce Fields

My mail client seems to be flagging all your messages as duplicates of each
other.

Hm.  It may be that your headers have two Message-Id's...

Message-Id: [EMAIL PROTECTED]
X-Mailer: git-send-email 1.5.3.7.949.g2221a6
Message-Id:
[EMAIL PROTECTED]


... the second of which is pretty weird (and is the same for every message.  Is
that a git-send-email bug or something else?

--b.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers/scsi/: Spelling fixes

2007-12-17 Thread Mike Christie


Joe Perches wrote:

Signed-off-by: Joe Perches [EMAIL PROTECTED]



diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
index 57ce225..3cc21f5 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -1121,7 +1121,7 @@ iscsi_send(struct iscsi_conn *conn, struct iscsi_buf 
*buf, int size, int flags)
  * iscsi_sendhdr - send PDU Header via tcp_sendpage()
  * @conn: iscsi connection
  * @buf: buffer to write from
- * @datalen: lenght of data to be sent after the header
+ * @datalen: length of data to be sent after the header
  *
  * Notes:
  * (Tx, Fast Path)
@@ -1724,7 +1724,7 @@ send_hdr:
  * XMSTATE_BIT_SOL_DATA - send solicit data
  *
  *iscsi_tcp_ctask_xmit
- * XMSTATE_BIT_IMM_DATA - xmit managment data (??)
+ * XMSTATE_BIT_IMM_DATA - xmit management data (??)
  **/
 static int
 iscsi_tcp_ctask_xmit(struct iscsi_conn *conn, struct iscsi_cmd_task *ctask)


Olaf rewrote this code and it will not exist when James merges the 
patches, so you can drop the iscsi bits.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] include/asm-mips/: Spelling fixes

2007-12-17 Thread Joe Perches

On Mon, 2007-12-17 at 22:53 +0300, Sergei Shtylyov wrote:
  - * PCI interrupts will come in on either the INTA or INTD interrups lines,
  + * PCI interrupts will come in on either the INTA or INTD interrupts lines,
 interrupt here.

Quite right.
I did them by script and inspected, but didn't notice that one.
cheers, Joe

Signed-off-by: Joe Perches [EMAIL PROTECTED]
---
diff --git a/include/asm-mips/mach-wrppmc/mach-gt64120.h 
b/include/asm-mips/mach-wrppmc/mach-gt64120.h
index 00d8bf6..465234a 100644
--- a/include/asm-mips/mach-wrppmc/mach-gt64120.h
+++ b/include/asm-mips/mach-wrppmc/mach-gt64120.h
@@ -45,7 +45,7 @@
 #define GT_PCI_IO_SIZE 0x0200UL
 
 /*
- * PCI interrupts will come in on either the INTA or INTD interrups lines,
+ * PCI interrupts will come in on either the INTA or INTD interrupt lines,
  * which are mapped to the #2 and #5 interrupt pins of the MIPS.  On our
  * boards, they all either come in on IntD or they all come in on IntA, they
  * aren't mixed. There can be numerous PCI interrupts, so we keep a list of the


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers/net/: Spelling fixes

2007-12-17 Thread Chris Snook


Joe Perches wrote:

 drivers/net/atl1/atl1_hw.c |2 +-
 drivers/net/atl1/atl1_main.c   |2 +-


The atl1 code will be heavily reworked in the 2.6.25 merge window, so this may 
cause headaches.  Please remove these chunks before merging.


The spelling corrections themselves are fine, and I will ensure that the revised 
driver includes them, if the comments in question are still present at all once 
we're done with all the changes and cleanups.


-- Chris
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1] IPN: Inter Process Networking

2007-12-17 Thread david


On Mon, 17 Dec 2007, Ludovico Gardenghi wrote:


On Mon, Dec 17, 2007 at 04:10:19AM -0800, [EMAIL PROTECTED] wrote:


if you are talking network connections between virtual systems, then the
exiting tap interfaces would seem to do everything you are looking for. you
can add them to bridges, route between them, filter traffic between them
(at whatever layer you want with netfilter), use multicast, etc as you
would any real interface.

if, however, you are talking about non-network communications (your example
of sending raw video frames across the interface), and want multiple
processes to receive them, this sounds like exactly the thing that splice
was designed to do, distribute data to multiple recipiants simultaniously
and efficiantly.


I'll try to explain.

Our first interest was to be able to interconnect virtual, real, and partial
virtual machines. We developed VDE for this, it's a user-level L2
switch. Specific as it may be, it's quite popular as a simple but
flexible tool. It can interconnect UML, Qemu, UMView, slirp, everything that
can be connected to a tap interface, etc.

So, you say, it's a networking issue and we could live with tun/tap.
There's a major point here: at present, dealing with tun/tap, bridges,
routing is quite difficult if you are a *regular* user with *no*
capabilites at all. You have tun/tap persistency and association to a
specific user (or group, recently), at most. That's good - we don't want
regular users to mess with global networking rules and settings.

Think of a bunch of etherogeneous virtual machines, partial virtual
machines (i.e. VMs where only a subset of system calls may be
virtualized or not depending on the parameters - that's the case of
View-OS) that must be interconnected and that may or may not have a
connection to a real network interface (maybe via a tunnel towards a
different machine). There's no need for administrator intervention here.
Why should an user have to ask root to create lots of tap interfaces for
him, bind them in a bridge and set up filtering/routing rules? What
would the list of interfaces become when different users asked for the
same thing at the same time?

You could define a specific interconnecting bus, but we've already have
it: ethernet. VDE comes in help as it allows regular users to build
distributed ethernet networks.

VDE works fine, but at present often results in a bottleneck because of
the high number of user-processes involved and user-kernel-user switches
needed in order to transfer a single ethernet frame. Moving the core
inside the kernel would limit this problem and result in faster
communication with still no need for root intervention or global
namespace messing. (we're thinking if something can be done working with
containers or similar structures, both for networking and partial
virtualization, but that's another topic).


so it sounds like the real issue you are trying to deal with is that only 
root is allowed to make changes to the networking configuration, and you 
want to allow non-root users to make changes.


in doing this you started by duplicating the kernel networking 
functionality into userspace (your userspace L2 switch) and are running 
into performance problems so trying to push this into the kernel to reduce 
context switches.


besides your approach I see two other options on their way into the 
kernel.


1. no changes, run your switch in a VM and your users (with their group 
permissions) connect their VM interfaces to the interfaces of the VM 
running the switch/filtering. this allows them 'root' inside the VM where 
they can make all these changes.


this may have the same performance problems as your current userspace 
switch.


2. networking virtualization. there is work being done to be able to have 
what would be essentially multiple networking stacks on a machine to allow 
a VM/container to control some things without having to go through the 
tun/tap interface. This would allow a user to change the filtering rules 
without the changes being global.


however, note that if the VM's are more then just a test-bed and actually 
need to talk to the outside world, at some point they will need to connect 
to the real interfaces, and making that connection should still require 
superuser privilages on the master kernel.


besides, useing the standard networking stack has the advantage that if 
you end up needing to spread your VM's across multiple machines the 
support is already there, where adding a new IPC mechanism will require 
figuring out how to extend that mechanism across machines.


It also doesn't require the applications to be coded specificly for your 
mechanism. they just use standard networking API's and the virtual 
connections happen for them.



So we started thinking how to use existing kernel structures, and we
concluded that:

- no existing kernel structures appeared to be optimal for this work;
- if we've had to design a new structure, it would have been more
  useful if we

Re: 2.6.24-rc5: tape drive not responding

2007-12-17 Thread John Stoffel

 Andrew == Andrew Morton [EMAIL PROTECTED] writes:

Andrew On Mon, 17 Dec 2007 11:25:51 +0900 FUJITA Tomonori [EMAIL PROTECTED] 
wrote:
 On Sun, 16 Dec 2007 20:05:51 -0500
 John Stoffel [EMAIL PROTECTED] wrote:
  
  [  273.382057] sd 12:0:0:3: Attached scsi generic sg13 type 0
  [  276.244872] [ cut here ]
  [  276.300215] kernel BUG at include/linux/scatterlist.h:59!
  [  276.364873] invalid opcode:  [#1] SMP 
  [  276.414346] Modules linked in:
  [  276.451148] 
  [  276.469036] Pid: 1824, comm: stinit Not tainted (2.6.24-rc5 #2)
  [  276.539940] EIP: 0060:[c0343c30] EFLAGS: 00010213 CPU: 0
  [  276.605651] EIP is at st_do_scsi+0x2e0/0x340
  [  276.656788] EAX:  EBX:  ECX: c16ef780 EDX: f7c4f050
  [  276.731847] ESI: f7c4f7d0 EDI: 1000 EBP: f7c4f000 ESP: f712bdf8
  [  276.806904]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
  [  276.871568] Process stinit (pid: 1824, ti=f712b000 task=f750a030 
  task.ti=f712b000)
  [  276.960139] Stack: 0003 f7c4f050   00d59f80 
   f776fe20 c03468a0 
  [  277.062012]00d0 f712be9c f7d2a000 f776fe20 f7d2a018 
   0006 f712be9c 
  [  277.163890]f7d2a000 f712beac f7c4f000 c0345790 0006 
  0002 000dbba0  
  [  277.265771] Call Trace:
  [  277.297383]  [c03468a0] st_sleep_done+0x0/0x70
  [  277.352894]  [c0345790] check_tape+0x510/0x640
  [  277.408414]  [c0346cfb] st_open+0x18b/0x220
  [  277.460803]  [c01707e0] exact_match+0x0/0x10
  [  277.514237]  [c0346b70] st_open+0x0/0x220
  [  277.564553]  [c0170ebf] chrdev_open+0x9f/0x190
  [  277.620069]  [c0170e20] chrdev_open+0x0/0x190
  [  277.674543]  [c016c86f] __dentry_open+0xaf/0x1b0
  [  277.732136]  [c016ca25] nameidata_to_filp+0x35/0x40
  [  277.792847]  [c016ca7b] do_filp_open+0x4b/0x60
  [  277.848364]  [c016c732] get_unused_fd_flags+0x52/0xd0
  [  277.911153]  [c016cadc] do_sys_open+0x4c/0xe0
  [  277.965629]  [c016cbac] sys_open+0x1c/0x20
 
 I think that you need the following patch for the scatterlist problem:
 
 http://marc.info/?l=linux-scsim=119770154127770w=2

Andrew err, you sent that patch to John a day earlier too.

Andrew John, can you please apply, test and report?

Happily, this seems to fix the problem with the above crash on
2.6.24-rc5-mm1, I've also left the fix in 2.6.24-rc5 and I'll be
testing that in my next reboot.  It's looking good!

So, this regression is fixed in 2.6.24-rc5-mm1.

Next, it would be nice to rate limit the Parity error detected...
messages from the Symbios driver, I'll see if I can hack something up
in the next day or so.

Thanks,
John
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Final kprobes rollup patches

2007-12-17 Thread Harvey Harrison

On Mon, 2007-12-17 at 17:06 +0100, Ingo Molnar wrote:
 * Masami Hiramatsu [EMAIL PROTECTED] wrote:
 
   cool! Please Cc: lkml and Harvey as well so that there's less 
   overlap in unification work - Harvey spent quite some time unifying 
   and cleaning up the kprobes code during the past week.
  
  Should I rewrite it based on current git tree?
  My patch includes 3 part of patches.
  - 2 Bugfix patches (which is not merged yet.)
  - 2 booster patches (ditto)
  - 2 unification patches (most of this patches are already done by Harvey's 
  patch)
 
 would it be easier/more robust to first did the unification patches and 
 then get the bugfixes and new features in? That would give us your 
 bugfixes and new features on both 32-bit and 64-bit at the same time.
 
 feel free to do whichever approach you prefer - but it would be nice to 
 preserve the unification and cleanup work done by Harvey.
 
 btw., is any of your bugfixes 2.6.24 material?
 

Well, I'll admit to being a little disappointed if my work doesn't make
it in, but there are bugfixes here.  I think my cleanup breakout is
better in the more-finegrained changes sense.  If you decide to keep
mine I'll rebase Masami's patches 1-4 on top of that and send it by
him for resubmittal.  But I'll leave it to Ingo to decide how
to procede.

Harvey

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 1/2] timerfd - make hrtimer_forward() to return a u64

2007-12-17 Thread Davide Libenzi

This patch makes hrtimer_forward() to return a u64 instead of unsigned long.
Since timerfd returns the number of timer ticks in a u64 variable, and
hrtimer_forward() is used to calculate the timer ticks, the patch allow full
64 bit usage even on 32 bit platforms. The core of the hrtimer_forward() ticks
calculation, ktime_divns(), was already having the result in u64 and it was
chopping it to unsigned long.
Andrew, this goes on top of the ones you already have in -mm.



Signed-off-by: Davide Libenzi [EMAIL PROTECTED]


- Davide


---
 fs/timerfd.c|6 +++---
 include/linux/hrtimer.h |   10 +-
 kernel/hrtimer.c|9 -
 kernel/posix-timers.c   |9 +
 4 files changed, 17 insertions(+), 17 deletions(-)

Index: linux-2.6.mod/include/linux/hrtimer.h
===
--- linux-2.6.mod.orig/include/linux/hrtimer.h  2007-12-13 16:37:36.0 
-0800
+++ linux-2.6.mod/include/linux/hrtimer.h   2007-12-14 16:05:23.0 
-0800
@@ -295,12 +295,12 @@
 }
 
 /* Forward a hrtimer so it expires after now: */
-extern unsigned long
+extern u64
 hrtimer_forward(struct hrtimer *timer, ktime_t now, ktime_t interval);
 
 /* Forward a hrtimer so it expires after the hrtimer's current now */
-static inline unsigned long hrtimer_forward_now(struct hrtimer *timer,
-   ktime_t interval)
+static inline u64 hrtimer_forward_now(struct hrtimer *timer,
+ ktime_t interval)
 {
return hrtimer_forward(timer, timer-base-get_time(), interval);
 }
@@ -322,9 +322,9 @@
 extern void __init hrtimers_init(void);
 
 #if BITS_PER_LONG  64
-extern unsigned long ktime_divns(const ktime_t kt, s64 div);
+extern u64 ktime_divns(const ktime_t kt, s64 div);
 #else /* BITS_PER_LONG  64 */
-# define ktime_divns(kt, div)  (unsigned long)((kt).tv64 / (div))
+# define ktime_divns(kt, div)  (u64)((kt).tv64 / (div))
 #endif
 
 /* Show pending timers: */
Index: linux-2.6.mod/kernel/hrtimer.c
===
--- linux-2.6.mod.orig/kernel/hrtimer.c 2007-12-13 16:37:53.0 -0800
+++ linux-2.6.mod/kernel/hrtimer.c  2007-12-13 16:41:42.0 -0800
@@ -306,7 +306,7 @@
 /*
  * Divide a ktime value by a nanosecond value
  */
-unsigned long ktime_divns(const ktime_t kt, s64 div)
+u64 ktime_divns(const ktime_t kt, s64 div)
 {
u64 dclc, inc, dns;
int sft = 0;
@@ -321,7 +321,7 @@
dclc = sft;
do_div(dclc, (unsigned long) div);
 
-   return (unsigned long) dclc;
+   return dclc;
 }
 #endif /* BITS_PER_LONG = 64 */
 
@@ -655,10 +655,9 @@
  * Forward the timer expiry so it will expire in the future.
  * Returns the number of overruns.
  */
-unsigned long
-hrtimer_forward(struct hrtimer *timer, ktime_t now, ktime_t interval)
+u64 hrtimer_forward(struct hrtimer *timer, ktime_t now, ktime_t interval)
 {
-   unsigned long orun = 1;
+   u64 orun = 1;
ktime_t delta;
 
delta = ktime_sub(now, timer-expires);
Index: linux-2.6.mod/kernel/posix-timers.c
===
--- linux-2.6.mod.orig/kernel/posix-timers.c2007-12-13 16:38:15.0 
-0800
+++ linux-2.6.mod/kernel/posix-timers.c 2007-12-13 16:45:20.0 -0800
@@ -256,8 +256,9 @@
if (timr-it.real.interval.tv64 == 0)
return;
 
-   timr-it_overrun += hrtimer_forward(timer, timer-base-get_time(),
-   timr-it.real.interval);
+   timr-it_overrun += (unsigned int) hrtimer_forward(timer,
+   timer-base-get_time(),
+   timr-it.real.interval);
 
timr-it_overrun_last = timr-it_overrun;
timr-it_overrun = -1;
@@ -386,7 +387,7 @@
now = ktime_add(now, kj);
}
 #endif
-   timr-it_overrun +=
+   timr-it_overrun += (unsigned int)
hrtimer_forward(timer, now,
timr-it.real.interval);
ret = HRTIMER_RESTART;
@@ -662,7 +663,7 @@
 */
if (iv.tv64  (timr-it_requeue_pending  REQUEUE_PENDING ||
(timr-it_sigev_notify  ~SIGEV_THREAD_ID) == SIGEV_NONE))
-   timr-it_overrun += hrtimer_forward(timer, now, iv);
+   timr-it_overrun += (unsigned int) hrtimer_forward(timer, now, 
iv);
 
remaining = ktime_sub(timer-expires, now);
/* Return 0 only, when the timer is expired and not pending */
Index: linux-2.6.mod/fs/timerfd.c
===
--- linux-2.6.mod.orig/fs/timerfd.c 2007-12-13 16:49:46.0 -0800
+++ linux-2.6.mod/fs/timerfd.c  2007-12-14 16:04:36.0

[patch 2/2] timerfd - make the returned time to be the remaining time till the next expiration

2007-12-17 Thread Davide Libenzi

Make the returned time to be the remaining time till the next expiration.
If the timer is already expired, and there's no next expiration, zero will
be returned.
Andrew, this goes on top of the ones you already have in -mm.



Signed-off-by: Davide Libenzi [EMAIL PROTECTED]


- Davide


---
 fs/timerfd.c |   13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

Index: linux-2.6.mod/fs/timerfd.c
===
--- linux-2.6.mod.orig/fs/timerfd.c 2007-12-14 16:04:36.0 -0800
+++ linux-2.6.mod/fs/timerfd.c  2007-12-14 16:05:32.0 -0800
@@ -49,6 +49,15 @@
return HRTIMER_NORESTART;
 }
 
+static ktime_t timerfd_get_remaining(struct timerfd_ctx *ctx) {
+   ktime_t now, remaining;
+
+   now = ctx-tmr.base-get_time();
+   remaining = ktime_sub(ctx-tmr.expires, now);
+
+   return remaining.tv64  0 ? ktime_set(0, 0): remaining;
+}
+
 static void timerfd_setup(struct timerfd_ctx *ctx, int flags,
  const struct itimerspec *ktmr)
 {
@@ -240,7 +249,7 @@
if (ctx-expired  ctx-tintv.tv64)
hrtimer_forward_now(ctx-tmr, ctx-tintv);
 
-   kotmr.it_value = ktime_to_timespec(ctx-tmr.expires);
+   kotmr.it_value = ktime_to_timespec(timerfd_get_remaining(ctx));
kotmr.it_interval = ktime_to_timespec(ctx-tintv);
 
/*
@@ -274,7 +283,7 @@
hrtimer_forward_now(ctx-tmr, ctx-tintv) - 1;
hrtimer_restart(ctx-tmr);
}
-   kotmr.it_value = ktime_to_timespec(ctx-tmr.expires);
+   kotmr.it_value = ktime_to_timespec(timerfd_get_remaining(ctx));
kotmr.it_interval = ktime_to_timespec(ctx-tintv);
spin_unlock_irq(ctx-wqh.lock);
fput(file);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

problem with ending requests asynchronously in my block device driver

2007-12-17 Thread cable_plug


Hi, 

I've a block device driver which does the following, 

Inside the request function I do something like this: 
request(fn) { 

 while ((req = elv_next_request(q)) != NULL) { 
set up the request; 
 spin_unlock_irq(q-queue_lock); 
call the transfer(set_up_req) function; 
spin_lock_irq(q-queue_lock); 
} 
   spin_unlock_irq (q-queue_lock); 
/* allow callback to execute as it needs the lock!!! */ 
spin_lock_irq (q-queue_lock); 


} 
and the transfer function calls the scsi_execute_asyn() with the
callback function doing the end request. So, the ending of the request is
done like below: 

callback(fn) { 

 spin_lock_irqsave(q-queue_lock, flags); 
if (!end_that_request_first(set_up_req-req, cmpstatus, 
set_up_req-req-nr_sectors)) { 
add_disk_randomness(...); 
end_that_request_last(set_up_req-req,0); 
} 
spin_unlock_irqrestore(q-queue_lock, flags); 
} 


This code works fine with most of the kernel versions, but fails on some
like , Linux 2.6.18-8.el5-xen 

Please help me to find out where I'm going wrong? 

when I say 'fails' it just hangs without any error I'm using dt(Data
test) to write to the disk. The logs show that all the requests that have
been sent for processing, have completed sucessfully. Its just that new
requests never enter the request function. So, the dt writes almost half the
data and then simply hangs. 

  
  The actual code does nothing but, call the scsi_execute_async , which 
 later on calls the callback function which is used to end the request. 
 So, both the callback function and the request function need to share 
 the queue lock. So the code samples I sent cover all the aspects of my 
 program. What I'm looking for here is how can I end the requests 
 asynchronously much later after the request processing is done. Please note 
 here that the asynchronous end requests is done by the callback function 
 of the scsi_execute_async, which needs to share the queue lock with 
 the request function. 

  when I say 'fails' it just hangs without any error I'm using 
 dt(Data 
test) to write to the disk. The logs show that all the requests that 
 have 
been sent for processing, have completed successfully. Its just that new 
requests never enter the request function. So, the dt writes almost 
 half the 
data and then simply hangs. 


Thanks in advance for an early reply. 
Anil P.
-- 
View this message in context: 
http://www.nabble.com/problem-with-ending-requests-asynchronously-in-my-block-device-driver-tp14374028p14374028.html
Sent from the linux-kernel mailing list archive at Nabble.com.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.24-rc5-mm 3/3] gpiolib: obsolete drivers/i2c/chips/pca9539.c

2007-12-17 Thread Jean Delvare

Hi David,

On Mon, 17 Dec 2007 10:09:53 -0800, David Brownell wrote:
  Date: Mon, 17 Dec 2007 14:33:27 +0800
  From: eric miao [EMAIL PROTECTED]

  for the following reasons:

  1. there is currently no known users of this driver

  2. the functionality of this driver is well supported with the recent
 proposed drivers/gpio/pca9539.c, using GPIO_LIB

  Signed-off-by: eric miao [EMAIL PROTECTED]
  Acked-by: Ben Gardner [EMAIL PROTECTED]
  ---
   Documentation/i2c/chips/pca9539 |   47 
   drivers/i2c/chips/Kconfig   |   10 --
   drivers/i2c/chips/Makefile  |1 -
   drivers/i2c/chips/pca9539.c |  196 --

 Jean, do you sign off on this?  In any case I think this should
 be going through your I2C patches.

 I'd be a trifle uneasy just deleting this, because it's possible
 there are *unknown* users ... and also because nobody's yet done
 a userspace interface to the gpiolib infrastructure.  (It seems
 to be the usual case of nobody wanting such a thing quite enough
 to write the code.)

 I'd be more comfortable marking it as obsolete and flagging it
 for removal a release or two after Eric's new version merges ...
 though maybe that's just paranoia.

I'm fine with this and I agree that it would be safer, however please
note that both drivers are mutually exclusive because they have the
same name, meaning that deprecating the old driver is not enough, you
also need Kconfig magic to make sure that both drivers aren't built at
the same time. Or alternatively the old driver could be renamed... I
don't really care myself, I'll take whatever patch you or Eric submit.

-- 
Jean Delvare
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers/i2c/: Spelling fixes

2007-12-17 Thread Jean Delvare

Hi Joe,

On Mon, 17 Dec 2007 11:30:34 -0800, Joe Perches wrote:
 
 Signed-off-by: Joe Perches [EMAIL PROTECTED]
 ---
  drivers/i2c/busses/i2c-at91.c |2 +-
  drivers/i2c/busses/i2c-powermac.c |2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
 index 9c8b6d5..c09b036 100644
 --- a/drivers/i2c/busses/i2c-at91.c
 +++ b/drivers/i2c/busses/i2c-at91.c
 @@ -135,7 +135,7 @@ static int xfer_write(struct i2c_adapter *adap, unsigned 
 char *buf, int length)
   * Generic i2c master transfer entrypoint.
   *
   * Note: We do not use Atmel's feature of storing the internal device 
 address.
 - * Instead the internal device address has to be written using a seperate
 + * Instead the internal device address has to be written using a separate
   * i2c message.
   * 
 http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2004-September/024411.html
   */
 diff --git a/drivers/i2c/busses/i2c-powermac.c 
 b/drivers/i2c/busses/i2c-powermac.c
 index 0ab4f26..7813127 100644
 --- a/drivers/i2c/busses/i2c-powermac.c
 +++ b/drivers/i2c/busses/i2c-powermac.c
 @@ -94,7 +94,7 @@ static s32 i2c_powermac_smbus_xfer( struct i2c_adapter* 
 adap,
   break;
  
   /* Note that these are broken vs. the expected smbus API where
 -  * on reads, the lenght is actually returned from the function,
 +  * on reads, the length is actually returned from the function,
* but I think the current API makes no sense and I don't want
* any driver that I haven't verified for correctness to go
* anywhere near a pmac i2c bus anyway ...

Applied, thank you.

-- 
Jean Delvare
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/7] kobject: fix the documentation of how kobject_set_name works

2007-12-17 Thread Greg Kroah-Hartman

Thanks to Dave Young [EMAIL PROTECTED] for pointing out that I
forgot to update the comment when I rewrote kobject_set_name.

Cc: Dave Young [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
 lib/kobject.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/lib/kobject.c b/lib/kobject.c
index b52e9f4..3590f02 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -234,13 +234,13 @@ int kobject_register(struct kobject * kobj)
 
 
 /**
- * kobject_set_name - Set the name of an object
- * @kobj:  object.
- * @fmt:   format string used to build the name
+ * kobject_set_name - Set the name of a kobject
+ * @kobj: kobject to name
+ * @fmt: format string used to build the name
  *
- * If strlen(name) = KOBJ_NAME_LEN, then use a dynamically allocated
- * string that @kobj-k_name points to. Otherwise, use the static 
- * @kobj-name array.
+ * This sets the name of the kobject.  If you have already added the
+ * kobject to the system, you must call kobject_rename() in order to
+ * change the name of the kobject.
  */
 int kobject_set_name(struct kobject * kobj, const char * fmt, ...)
 {
-- 
1.5.3.7

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/7] tipar: remove obsolete module

2007-12-17 Thread Greg Kroah-Hartman

From: Romain Liévin [EMAIL PROTECTED]

tipar: remove obsolete module

The tipar character driver was used to implement bit-banging access
to Texas Instruments parallel link cable. A user-land method now
exists thru PPDEV  PARPORT.

Signed-off-by: Romain Liévin [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
 Documentation/tipar.txt |   93 
 MAINTAINERS |5 -
 drivers/char/Kconfig|   22 --
 drivers/char/tipar.c|  557 ---
 include/linux/ticable.h |   44 
 5 files changed, 0 insertions(+), 721 deletions(-)
 delete mode 100644 Documentation/tipar.txt
 delete mode 100644 drivers/char/tipar.c
 delete mode 100644 include/linux/ticable.h

diff --git a/Documentation/tipar.txt b/Documentation/tipar.txt
deleted file mode 100644
index 67133ba..000
--- a/Documentation/tipar.txt
+++ /dev/null
@@ -1,93 +0,0 @@
-
-   Parallel link cable for Texas Instruments handhelds
-   ===
-
-
-Author: Romain Lievin
-Homepage: http://lpg.ticalc.org/prj_tidev/index.html
-
-
-INTRODUCTION:
-
-This is a driver for the very common home-made parallel link cable, a cable 
-designed for connecting TI8x/9x graphing calculators (handhelds) to a computer
-or workstation (Alpha, Sparc). Given that driver is built on parport, the 
-parallel port abstraction layer, this driver is architecture-independent.
-
-It can also be used with another device plugged on the same port (such as a
-ZIP drive). I have a 100MB ZIP and both of them work fine!
-
-If you need more information, please visit the 'TI drivers' homepage at the URL
-above.
-
-WHAT YOU NEED:
-
-A TI calculator and a program capable of communicating with your calculator.
-
-TiLP will work for sure (since I am its developer!). yal92 may be able to use
-it by changing tidev for tipar (may require some hacking...).
-
-HOW TO USE IT:
-
-You must have first compiled parport support (CONFIG_PARPORT_DEV): either 
-compiled in your kernel, either as a module. 
-
-Next, (as root):
-
-   modprobe parport
-   modprobe tipar
-
-If it is not already there (it usually is), create the device:
-
-   mknod /dev/tipar0 c 115 0
-   mknod /dev/tipar1 c 115 1
-   mknod /dev/tipar2 c 115 2
-
-You will have to set permissions on this device to allow you to read/write
-from it:
-
-   chmod 666 /dev/tipar[0..2]
-   
-Now you are ready to run a linking program such as TiLP. Be sure to configure 
-it properly (RTFM).
-   
-MODULE PARAMETERS:
-
-  You can set these with:  modprobe tipar NAME=VALUE
-  There is currently no way to set these on a per-cable basis.
-
-  NAME: timeout
-  TYPE: integer
-  DEFAULT: 15
-  DESC: Timeout value in tenth of seconds. If no data is available once this 
-   time has expired then the driver will return with a timeout error.
-
-  NAME: delay
-  TYPE: integer
-  DEFAULT: 10
-  DESC: Inter-bit delay in micro-seconds. A lower value gives an higher data
-   rate but makes transmission less reliable.
-
-These parameters can be changed at run time by any program via ioctl(2) calls 
-as listed in ./include/linux/ticable.h.
-
-Rather than write 50 pages describing the ioctl() and so on, it is
-perhaps more useful you look at ticables library (dev_link.c) that demonstrates
-how to use them, and demonstrates the features of the driver. This is
-probably a lot more useful to people interested in writing applications
-that will be using this driver.
-
-QUIRKS/BUGS:
-
-None.
-
-HOW TO CONTACT US:
-
-You can email me at [EMAIL PROTECTED] Please prefix the subject line
-with TIPAR:  so that I am certain to notice your message.
-You can also mail JB at [EMAIL PROTECTED] He packaged these drivers for Debian.
-
-CREDITS:
-
-The code is based on tidev.c  parport.c.
-The driver has been developed independently of Texas Instruments.
diff --git a/MAINTAINERS b/MAINTAINERS
index 9507b42..a7caced 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3699,11 +3699,6 @@ M:   [EMAIL PROTECTED]
 L: linux-kernel@vger.kernel.org
 S: Maintained
 
-TI PARALLEL LINK CABLE DRIVER
-P: Romain Lievin
-M: [EMAIL PROTECTED]
-S: Maintained
-
 TIPC NETWORK LAYER
 P: Per Liden
 M: [EMAIL PROTECTED]
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index a509b8d..ef1ed5d 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -543,28 +543,6 @@ config PPDEV
 
  If unsure, say N.
 
-config TIPAR
-   tristate Texas Instruments parallel link cable support
-   depends on PARPORT
-   ---help---
- If you own a Texas Instruments graphing calculator and use a
- parallel link cable, then you might be interested in this driver.
-
- If you enable this driver, you will be able to communicate with
- your calculator through a set of device nodes under /dev. The
- main advantage of this driver is that you don't have to be root
-

[PATCH 4/7] Add Documentation for FAIR_USER_SCHED sysfs files

2007-12-17 Thread Greg Kroah-Hartman

From: Dhaval Giani [EMAIL PROTECTED]

This patch adds documentation about /sys/kernel/uids/uid/cpu_share
to Documentation/ABI.

Signed-off-by: Dhaval Giani [EMAIL PROTECTED]
Cc: Ingo Molnar [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
 Documentation/ABI/testing/sysfs-kernel-uids |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-kernel-uids

diff --git a/Documentation/ABI/testing/sysfs-kernel-uids 
b/Documentation/ABI/testing/sysfs-kernel-uids
new file mode 100644
index 000..648d65d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-uids
@@ -0,0 +1,14 @@
+What:  /sys/kernel/uids/uid/cpu_shares
+Date:  December 2007
+Contact:   Dhaval Giani [EMAIL PROTECTED]
+   Srivatsa Vaddagiri [EMAIL PROTECTED]
+Description:
+   The /sys/kernel/uids/uid/cpu_shares tunable is used
+   to set the cpu bandwidth a user is allowed. This is a
+   propotional value. What that means is that if there
+   are two users logged in, each with an equal number of
+   shares, then they will get equal CPU bandwidth. Another
+   example would be, if User A has shares = 1024 and user
+   B has shares = 2048, User B will get twice the CPU
+   bandwidth user A will. For more details refer
+   Documentation/sched-design-CFS.txt
-- 
1.5.3.7

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/7] HOWTO: change addresses of maintainer and lxr url for Korean HOWTO

2007-12-17 Thread Greg Kroah-Hartman

From: minchan kim [EMAIL PROTECTED]

So sorry. again My mail is set with EUC-kR.
I'll resend with UTF-8.

Signed-off-by: barrios [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
 Documentation/ko_KR/HOWTO |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO
index b51d7ca..a69135b 100644
--- a/Documentation/ko_KR/HOWTO
+++ b/Documentation/ko_KR/HOWTO
@@ -90,7 +90,7 @@ GPLì ê´í ì¦ì ì§ë¬¸ë¤ê³¼ ëµë³ë¤ì ë¤ìì 
ì°¸ì¡°íë¼.
 ê·¸ ê¸°ë¥ì ì´ë»ê² ì¬ì©íëì§ì ê´í ì¤ëªì ìíì¬ 
ìë¡ì´ ë¬¸ì íì¼ì
 ì¶ê°íë ê²ì ê¶ì¥íë¤. ì»¤ëì´ ì ì ì¤íì´ì¤ë¡ ë¸ì¶íë 
ì¸í°íì´ì¤ë¥¼
 ë³ê²½íê² ëë©´ ë³ê²½ì ì¤ëªíë ë©ë´ì¼ íì´ì§ë¤ì ëí 
í¨ì¹ë ì ë³´ë¥¼
[EMAIL PROTECTED] ë©ì¸í¸ëìê² ë³´ë¼ ê²ì ê¶ì¥íë¤.
[EMAIL PROTECTED] ë©ì¸í¸ëìê² ë³´ë¼ ê²ì ê¶ì¥íë¤.
 
 ë¤ìì ì»¤ë ìì¤ í¸ë¦¬ì ìë ì½ì´ì¼ í  íì¼ë¤ì 
ë¦¬ì¤í¸ì´ë¤.
   README
@@ -212,7 +212,7 @@ Documentation/DocBook/ ëë í ë¦¬ ë´ìì 
ë§ë¤ì´ì§ë©° PDF, Postscript, H
 ê²ì Linux Cross-Reference projectì´ë©° ê·¸ê²ì ìê¸° ì°¸ì¡° ë°©ìì´ë©°
 ìì¤ì½ëë¥¼ ì¸ë±ì¤ë ì¹ íì´ì§ë¤ì ííë¡ ë³´ì¬ì¤ë¤. 
ìµì ì ë©ì§ ì»¤ë
 ì½ë ì ì¥ìë ë¤ìì íµíì¬ ì°¸ì¡°í  ì ìë¤.
-  http://sosdg.org/~coywolf/lxr/
+  http://users.sosdg.org/~qiyong/lxr/
 
 
 ê°ë° íë¡ì¸ì¤
@@ -327,7 +327,7 @@ Andrew Mortonì ìí´ ë°°í¬ë ì¤íì ì¸ ì»¤ë 
í¨ì¹ë¤ì´ë¤. Andrewë
 - ACPI development tree, Len Brown [EMAIL PROTECTED] 
 git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
 
-- Block development tree, Jens Axboe [EMAIL PROTECTED]
+- Block development tree, Jens Axboe [EMAIL PROTECTED]
 git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
 
 - DRM development tree, Dave Airlie [EMAIL PROTECTED]
-- 
1.5.3.7

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/7] add stable_api_nonsense.txt in korean

2007-12-17 Thread Greg Kroah-Hartman

From: barrios [EMAIL PROTECTED]

Signed-off-by: barrios [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
 Documentation/ko_KR/stable_api_nonsense.txt |  195 +++
 1 files changed, 195 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/ko_KR/stable_api_nonsense.txt

diff --git a/Documentation/ko_KR/stable_api_nonsense.txt 
b/Documentation/ko_KR/stable_api_nonsense.txt
new file mode 100644
index 000..8f2b0e1
--- /dev/null
+++ b/Documentation/ko_KR/stable_api_nonsense.txt
@@ -0,0 +1,195 @@
+NOTE:
+This is a version of Documentation/stable_api_nonsense.txt translated
+into korean
+This document is maintained by barrios [EMAIL PROTECTED]
+If you find any difference between this document and the original file or
+a problem with the translation, please contact the maintainer of this file.
+
+Please also note that the purpose of this file is to be easier to
+read for non English (read: korean) speakers and is not intended as
+a fork. So if you have any comments or updates for this file please
+try to update the original English file first.
+
+==
+ì´ ë¬¸ìë
+Documentation/stable_api_nonsense.txt
+ì íê¸ ë²ììëë¤.
+
+ììï¼ ê¹ë¯¼ì°¬ [EMAIL PROTECTED]
+ê°ìï¼ ì´ì ì´ë¯¸ [EMAIL PROTECTED]
+==
+
+ë¦¬ëì¤ ì»¤ë ëë¼ì´ë² ì¸í°íì´ì¤
+(ì¬ë¬ë¶ë¤ì ëª¨ë  ì§ë¬¸ì ëí ëµ ê·¸ë¦¬ê³  ë¤ë¥¸ ëªê°ì§)
+
+Greg Kroah-Hartman [EMAIL PROTECTED]
+
+ì´ ë¬¸ìë ë¦¬ëì¤ê° ì ë°ì´ëë¦¬ ì»¤ë ì¸í°íì´ì¤ë¥¼ ê°ì§ 
ìëì§, ì ë³íì§
+ìë(stable) ì»¤ë ì¸í°íì´ì¤ë¥¼ ê°ì§ ìëì§ë¥¼ ì¤ëªíê¸° 
ìí´ ì°ì¬ì¡ë¤.
+ì´ ë¬¸ìë ì»¤ëê³¼ ì ì ê³µê° ì¬ì´ì ì¸í°íì´ì¤ê° ìëë¼ 
ì»¤ë ë´ë¶ì
+ì¸í°íì´ì¤ë¤ì ì¤ëªíê³  ìë¤ë ê²ì ì ëíë¼. ì»¤ëê³¼ 
ì ì ê³µê° ì¬ì´ì
+ì¸í°íì´ì¤ë ìì©íë¡ê·¸ë¨ì´ ì¬ì©íë syscall 
ì¸í°íì´ì¤ì´ë¤. ê·¸ ì¸í°íì´ì¤ë
+ì¤ë«ëì ê±°ì ë³íì§ ììê³  ìì¼ë¡ë ë³íì§ ìì 
ê²ì´ë¤. ëë pre 0.9ìì
+ë§ë¤ì´ì¡ì§ë§ ìµì ì 2.6 ì»¤ë ë°°í¬ììë ì ëìíë 
íë¡ê·¸ë¨ì ê°ì§ê³ 
+ìë¤. ì´ ì¸í°íì´ì¤ë ì¬ì©ìì ìì©íë¡ê·¸ë¨ ê°ë°ìë¤ì´ 
ë³íì§ ìì ê²ì´ë¼ê³ 
+ì¬ê¸¸ì ìë ê²ì´ë¤.
+
+
+ì´ë¡
+
+ì¬ë¬ë¶ì ë³íì§ ìë ì»¤ë ì¸í°íì´ì¤ë¥¼ ìíë¤ê³  
ìê°íì§ë§ ì¤ì ë¡ë
+ê·¸ë ì§ ìì¼ë©° ì¬ì§ì´ë ê·¸ê²ì ììì±ì§ ëª»íë¤. 
ì¬ë¬ë¶ì´ ìíë ê²ì
+ìì ëê² ì¤íëë ëë¼ì´ë²ì´ë©° ëë¼ì´ë²ê° ë©ì¸ ì»¤ë 
í¸ë¦¬ì ìì ë
+ê·¸ë° ìì ì ì¸ ëë¼ì´ë²ë¥¼ ì»ì ì ìê² ëë¤. ëí 
ì¬ë¬ë¶ì ëë¼ì´ë²ê°
+ë©ì¸ ì»¤ë í¸ë¦¬ì ìë¤ë©´ ë¤ë¥¸ ë§ì ì¢ì ì´ì ë¤ì ì»ê² 
ëë¤. ê·¸ë¬í ê²ë¤ì´
+ë¦¬ëì¤ë¥¼ ê°ê±´íê³ , ìì ì ì´ë©°, ì±ìí ì´ìì²´ì ë¡ 
ë§ë¤ì´ ëìì¼ë¡ì¨
+ì¬ë¬ë¶ë¤ë¡ íì¬ê¸ ë°ë¡ ë¦¬ëì¤ë¥¼ ì¬ì©íê² ë§ëë 
ì´ì ì´ë¤.
+
+
+ìê°
+
+
+ì»¤ë ë´ë¶ì ì¸í°íì´ì¤ê° ë°ëë ê²ì ê±±ì íë©° ì»¤ë 
ëë¼ì´ë²ë¥¼ ìì±íê³ 
+ì¶ì´íë ì¬ëì ì ë§ ì´ìí ì¬ëì´ë¤. ì¸ìì ëë¤ìì 
ì¬ëë¤ì ì´ ì¸í°íì´ì¤ë¥¼
+ë³´ì§ëª»í  ê²ì´ë©° ì í ê±±ì íì§ë ìëë¤.
+
+ë¨¼ì , ëë closed ìì¤, hidden ìì¤, binary blobs, ìì¤ wrappers, 
ëë GPLë¡
+ë°°í¬ëìì§ë§ ìì¤ ì½ëë¥¼ ê°ê³  ìì§ ìì ì»¤ë 
ëë¼ì´ë²ë¤ì ì¤ëªíë ì´ë¤ ë¤ë¥¸
+ì©ì´ë¤ì ê´í ì´ë¤ ë²ì ì¸ ë¬¸ì ì ê´í´ìë ì¸ê¸íì§ 
ìì ê²ì´ë¤. ì´ë¤ ë²ì ì¸
+ì§ë¬¸ë¤ì ê°ì§ê³  ìë¤ë©´ ë³í¸ì¬ì ì°ë½íë¼. ëë 
íë¡ê·¸ëë¨¸ì´ë¯ë¡ ì¬ê¸°ì ê¸°ì ì ì¸
+ë¬¸ì ë¤ë§ì ì¤ëªíë ¤ê³  íë¤. (ë²ì ì¸ ë¬¸ì ë¥¼ ê²½ìíë 
ê²ì ìëë¤. ê·¸ë° ë¬¸ì ë¤ì
+ìì°í íì¤ì ìê³  ì¬ë¬ë¶ë¤ì íì ê·¸ ë¬¸ì ë¤ì 
ì¸ìíê³  ìì íìë ìë¤.)
+
+ì, ëê°ì§ì ì£¼ì ì£¼ì ê° ìë¤. ë°ì´ëë¦¬ ì»¤ë 
ì¸í°íì´ì¤ë¤ê³¼ ë³íì§ ìë
+ì»¤ë ìì¤ ì¸í°íì´ë¤. ê·¸ê²ë¤ì ìë¡ ìì¡´ì±ì ê°ì§ê³  
ìì§ë§ ë°ì´ëë¦¬
+ë¬¸ì ë¥¼ ë¨¼ì  íê³  ëì´ê° ê²ì´ë¤.
+
+
+
+ë°ì´ëë¦¬ ì»¤ë ì¸í°íì´ì¤
+
+ì°ë¦¬ê° ë³íì§ ìë ì»¤ë ìì¤ ì¸í°íì´ì¤ë¥¼ ê°ì§ê³  
ìë¤ê³  ê°ì íì. ê·¸ë¬ë©´
+ë°ì´ëë¦¬ ì¸í°íì´ì¤ ëí ìì°ì ì¼ë¡ ë³íì§ ììê¹? 
íë ¸ë¤. ë¦¬ëì¤ ì»¤ëì
+ê´í ë¤ì ì¬ì¤ë¤ì ìê°í´ë³´ë¼.
+   - ì¬ë¬ë¶ë¤ì´ ì¬ì©íë C ì»´íì¼ë¬ì ë²ì ¼ì ë°ë¼ ë¤ë¥¸ 
ì»¤ë ìë£ êµ¬ì¡°ë¤ì
+ ë¤ë¥¸ alignmnetë¤ì ê°ê² ë ê²ì´ê³  ë¤ë¥¸ 
ë°©ë²ì¼ë¡(í¨ìë¤ì inlineì¼ë¡
+ íëë, ìëë) ë¤ë¥¸ í¨ìë¤ì í¬í¨íë ê²ë 
ê°ë¥íë¤. ì¤ìí ê²ì
+ ê°ë³ì ì¸ í¨ì êµ¬ì±ì´ ìëë¼ ìë£ êµ¬ì¡° í¨ë©ì´ 
ë¬ë¼ì§ë¤ë ì

[PATCH 7/7] HOWTO: update misspelling and word incorrected

2007-12-17 Thread Greg Kroah-Hartman

From: barrios [EMAIL PROTECTED]

Signed-off-by: barrios [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
 Documentation/ko_KR/HOWTO |  140 +++--
 1 files changed, 71 insertions(+), 69 deletions(-)

diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO
index a69135b..029fca9 100644
--- a/Documentation/ko_KR/HOWTO
+++ b/Documentation/ko_KR/HOWTO
@@ -1,6 +1,6 @@
 NOTE:
 This is a version of Documentation/HOWTO translated into korean
-This document is maintained by minchan Kim  [EMAIL PROTECTED]
+This document is maintained by minchan Kim [EMAIL PROTECTED]
 If you find any difference between this document and the original file or
 a problem with the translation, please contact the maintainer of this file.
 
@@ -14,7 +14,7 @@ try to update the original English file first.
 Documentation/HOWTO
 ì íê¸ ë²ììëë¤.
 
-ììï¼ ê¹ë¯¼ì°¬ [EMAIL PROTECTED] 
+ììï¼ ê¹ë¯¼ì°¬ [EMAIL PROTECTED]
 ê°ìï¼ ì´ì ì´ë¯¸ [EMAIL PROTECTED]
 ==
 
@@ -23,11 +23,11 @@ Documentation/HOWTO
 
 ì´ ë¬¸ìë ì»¤ë ê°ë°ì ìì´ ê°ì¥ ì¤ìí ë¬¸ìì´ë¤. ì´ 
ë¬¸ìë
 ë¦¬ëì¤ ì»¤ë ê°ë°ìê° ëë ë²ê³¼ ë¦¬ëì¤ ì»¤ë ê°ë° 
ì»¤ë®¤ëí°ì ì¼íë
-ë²ì ë´ê³ ìë¤. ì»¤ë íë¡ê·¸ëë°ìê¸°ì ì ì¸ ì¸¡ë©´ê³¼ ê´ë ¨ë 
ë´ì©ë¤ì
-í¬í¨íì§ ìì¼ë ¤ê³  íìì§ë§ ì¬ë°ì¼ë¡ ì¬ë¬ë¶ì ìë´íë 
ë° ëìì´
+ë²ì ë´ê³ ìë¤. ì»¤ë íë¡ê·¸ëë°ì ê¸°ì ì ì¸ ì¸¡ë©´ê³¼ 
ê´ë ¨ë ë´ì©ë¤ì
+í¬í¨íì§ ìì¼ë ¤ê³  íìì§ë§ ì¬ë°ë¥¸ ê¸¸ë¡ ì¬ë¬ë¶ì 
ìë´íë ë°ë ëìì´
 ë  ê²ì´ë¤.
 
-ì´ ë¬¸ììì ì¤ëë ê²ì ë°ê²¬íë©´ ë¬¸ìì ìëìª½ì 
ëì´ë ë©ì¸í¸ëìê²
+ì´ ë¬¸ììì ì¤ëë ê²ì ë°ê²¬íë©´ ë¬¸ìì ìëìª½ì 
ëì´ë ë©ì¸íì´ëìê²
 í¨ì¹ë¥¼ ë³´ë´ë¬ë¼.
 
 
@@ -36,12 +36,12 @@ Documentation/HOWTO
 
 ì, ì¬ë¬ë¶ì ë¦¬ëì¤ ì»¤ë ê°ë°ìê° ëë ë²ì ë°°ì°ê³  
ì¶ìê°? ìëë©´
 ìì¬ë¡ë¶í°ì´ ì¥ì¹ë¥¼ ìí ë¦¬ëì¤ ëë¼ì´ë²ë¥¼ 
ìì±íìì¤ë¼ë ë§ì
-ë¤ìëê°? ì´ ë¬¸ìë ì¬ë¬ë¶ì´ ê²ªê² ë  ê³¼ì ê³¼ ì»¤ë®¤ëí°ì 
ì¼íë ë²ì
-ì¡°ì¸íì¬ ì¬ë¬ë¶ì ëª©ì ì ë¬ì±íê¸° ìí´ íìí ê² 
ëª¨ëë¥¼ ìë ¤ì£¼ë
-ê²ì´ë¤.
+ë¤ìëê°? ì´ ë¬¸ìì ëª©ì ì ì¬ë¬ë¶ì´ ê²ªê² ë  ê³¼ì ê³¼ 
ì»¤ë®¤ëí°ì íë ¥íë
+ë²ì ì¡°ì¸íì¬ ì¬ë¬ë¶ì ëª©ì ì ë¬ì±íê¸° ìí´ íìí ê² 
ëª¨ëë¥¼ ìë ¤ì£¼ê¸°
+ìí¨ì´ë¤.
 
-ì»¤ëì ëë¶ë¶ì Cë¡ ìì±ëìì´ê³  ëªëª ìí¤íì³ì 
ìì¡´ì ì¸ ë¶ë¶ì
-ì´ìë¸ë¦¬ë¡ ìì±ëìë¤. ì»¤ë ê°ë°ì ìí´ Cë¥¼ ì ì´í´íê³  
ìì´ì¼ íë¤.
+ì»¤ëì ëë¶ë¶ì Cë¡ ìì±ëì´ ìê³  ëªëª ìí¤íì³ì 
ìì¡´ì ì¸ ë¶ë¶ì
+ì´ìë¸ë¦¬ë¡ ìì±ëì´ ìë¤. ì»¤ë ê°ë°ì ìí´ Cë¥¼ ì 
ì´í´íê³  ìì´ì¼ íë¤.
 ì¬ë¬ë¶ì´ í¹ì  ìí¤íì³ì low-level ê°ë°ì í  ê²ì´ ìëë¼ë©´
 ì´ìë¸ë¦¬(í¹ì  ìí¤íì³)ë ì ììì¼ í  íìë ìë¤.
 ë¤ìì ì°¸ê³ ìì ë¤ì ê¸°ë³¸ì ì¶©ì¤í C êµì¡ì´ë ìëê°ì 
ê²½íì ê²¬ì£¼ì§ë
@@ -59,11 +59,11 @@ Documentation/HOWTO
 ì´ë¤ ì°¸ê³ ë¬¸ìë ìì§ ìë¤. ì ë³´ë¥¼ ì»ê¸° ìí´ìë gcc info 
(`info gcc`)íì´ì§ë¥¼
 ì´í´ë³´ë¼.
 
-ì¬ë¬ë¶ì ê¸°ì¡´ì ê°ë° ì»¤ë®¤ëí°ì ì¼íë ë²ì ë°°ì°ë ¤ê³  
íê³  ìë¤ë ê²ì
-ê¸°ìµíë¼. ì½ë©, ì¤íì¼, ì ì°¨ì ê´í íë¥í íì¤ì ê°ì§ 
ì¬ëë¤ì´ ëª¨ì¸
+ì¬ë¬ë¶ì ê¸°ì¡´ì ê°ë° ì»¤ë®¤ëí°ì íë ¥íë ë²ì ë°°ì°ë ¤ê³  
íê³  ìë¤ë ê²ì
+ê¸°ìµíë¼. ì½ë©, ì¤íì¼, í¨ìì ê´í íë¥í íì¤ì ê°ì§ 
ì¬ëë¤ì´ ëª¨ì¸
 ë¤ìí ê·¸ë£¹ì´ ìë¤. ì´ íì¤ë¤ì ì¤ëëì í¬ê³  
ì§ìì ì¼ë¡ ë¶ì°ë íë¤ì
-ìí´ ê°ì¥ ì¢ì ë°©ë²ì¼ë¡ ì¼íê¸°ìíì¬ ì°¾ì ê²ì ê¸°ì´ë¡ 
ë§ë¤ì´ì ¸ìë¤.
-ê·¸ íì¤ë¤ì ë¬¸ìíê° ì ëì´ ìê¸° ëë¬¸ì ê°ë¥íí ë¯¸ë¦¬ 
ë§ì íì¤ë¤ì
+ìí´ ê°ì¥ ì¢ì ë°©ë²ì¼ë¡ ì¼íê¸° ìíì¬ ì°¾ì ê²ì ê¸°ì´ë¡ 
ë§ë¤ì´ì ¸ ìë¤.
+ê·¸ íì¤ë¤ì ë¬¸ìíê° ì ëì´ìê¸° ëë¬¸ì ê°ë¥íí ë¯¸ë¦¬ 
ë§ì íì¤ë¤ì
 ê´íì¬ ë°°ì°ë ¤ê³  ìëíë¼. ë¤ë¥¸ ì¬ëë¤ì ì¬ë¬ë¶ì´ë 
ì¬ë¬ë¶ì íì¬ê°
 ì¼íë ë°©ìì ì ìíë ê²ì ìíì§ë ìëë¤.
 
@@ -73,7 +73,7 @@ Documentation/HOWTO
 
 ë¦¬ëì¤ ì»¤ë ìì¤ ì½ëë GPLë¡ ë°°í¬(release)ëìë¤. 
ìì¤í¸ë¦¬ì ë©ì¸
 ëë í ë¦¬ì ìë ë¼ì´ì¼ì¤ì ê´íì¬ ìì¸íê² ì°ì¬ ìë 
COPYINGì´ë¼ë
-íì¼ì ë´ë¼.ì¬ë¬ë¶ì´ ë¼ì´ì¼ì¤ì ê´í ë ê¹ì ë¬¸ì ë¥¼ 
ê°ì§ê³  ìë¤ë©´
+íì¼ì ë´ë¼. ì¬ë¬ë¶ì´ ë¼ì´ì¼ì¤ì ê´í ë ê¹ì ë¬¸ì ë¥¼ 
ê°ì§ê³  ìë¤ë©´
 ë¦¬ëì¤ ì»¤ë ë©ì¼ë§ ë¦¬ì¤í¸ì ë¬»ì§ë§ê³  ë³í¸ì¬ì 
ì°ë½íë¼. ë©ì¼ë§
 ë¦¬ì¤í¸ë¤ì

Re: [PATCH] drivers/net/: Spelling fixes

2007-12-17 Thread Pavel Roskin


On Mon, 2007-12-17 at 11:40 -0800, Joe Perches wrote:
 Signed-off-by: Joe Perches [EMAIL PROTECTED]

 diff --git a/drivers/net/wireless/orinoco.h
 b/drivers/net/wireless/orinoco.h
 index 4720fb2..703a4cf 100644
 --- a/drivers/net/wireless/orinoco.h
 +++ b/drivers/net/wireless/orinoco.h
 @@ -108,7 +108,7 @@ struct orinoco_private {
   int scan_inprogress;/* Scan pending... */
   u32 scan_mode;  /* Type of scan done */
   char *  scan_result;/* Result of previous scan */
 - int scan_len;   /* Lenght of result */
 + int scan_len;   /* Length of result */
  };
  
  #ifdef ORINOCO_DEBUG

Acked-by: Pavel Roskin [EMAIL PROTECTED]

Actually, I don't think such minor comment fixes need to be reviewed by
the maintainers.  Thanks anyway.

-- 
Regards,
Pavel Roskin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arch/ppc/: Spelling fixes

2007-12-17 Thread Vitaly Bordug

On Mon, 17 Dec 2007 11:30:14 -0800
Joe Perches wrote:

 
 Signed-off-by: Joe Perches [EMAIL PROTECTED]
 ---
  arch/ppc/syslib/ppc8xx_pic.c |2 +-
  arch/ppc/syslib/ppc_sys.c|2 +-
I'm not really sure we should still care about typos in
arch/ppc..



-- 
Sincerely, Vitaly
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: swapping in 2.6.24-rc5-git3

2007-12-17 Thread Lukas Hejtmanek

On Mon, Dec 17, 2007 at 06:15:32PM +0100, Jan Kara wrote:
   Yes, that's quite unpleasant. How much memory do you have? If you have
 some time, you can try playing with the code in mm/vmscan.c to find out
 what's happening in your case (putting some debugging output in
 shrink_active_list() etc...

I think it is a regression in recent rc versions as I use 2.6.24-xx kernels on
my new laptop from the very beginnig I have the laptopt and I did not notice
such behaviour before.

I have 1 GB RAM and I was coping a 2GB file from the network to the laptop.
After the operation, 600MB of the swap area has been consumed. At the
beginning of the copy, the swap area was empty.

-- 
Lukáš Hejtmánek
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers/ide/: Spelling fixes

2007-12-17 Thread Bartlomiej Zolnierkiewicz

On Monday 17 December 2007, Joe Perches wrote:
 
 Signed-off-by: Joe Perches [EMAIL PROTECTED]

applied
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2] ipwireless_cs driver for 4G PC Card

2007-12-17 Thread Andrew Morton

On Mon, 17 Dec 2007 13:58:09 +0100 (CET)
Jiri Kosina [EMAIL PROTECTED] wrote:

 On Mon, 17 Dec 2007, Andrew Morton wrote:
 
   Andrew, what is your position on merging this into your 2.6.25 queue 
   please? David has fixed all the issues that came up during review, so 
   it seems to be that it's time for the driver to be merged during the 
   upcoming merge window. If you take it, I am perfectly fine with you 
   dropping the ipwireless_cs git tree from -mm lineup.
  I'd have thought that you'd merge it into git-ipwireless_cs.patch and that
  you would then take care of merging it into mainline at an appropriate
  time?
 
 I'd normally send this through PCMCIA maintainer's tree, but as long as 
 there is no such thing, I thought that merging through you is the best 
 thing to do. I don't want to bother Linus with pull request for a single 
 new driver.
 

Linus will cope ;)

Assuming that you've reviewed the driver and have some understanding of
what it does and how it does it, you're way ahead of me.  Please go ahead
and merge it when you think that is appropriate.  
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers/net/: Spelling fixes

2007-12-17 Thread Joe Perches

On Mon, 2007-12-17 at 15:40 -0500, Pavel Roskin wrote:
 On Mon, 2007-12-17 at 11:40 -0800, Joe Perches wrote:
 I don't think such minor comment fixes need to be reviewed by
 the maintainers.  Thanks anyway.

I'd like to know who pushes what source tree sections forward.

I have a script that uses annotated MAINTAINERS sections
to forward patches to appropriate maintainers.  That script
generated the CC's.

To me the question is who pushes.

If it's not a maintainer, who does?  Anyone have list?


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

2007-12-17 Thread Rene Herman


On 17-12-07 17:12, Alan Cox wrote:


I don't think we should be offering udelay based delays at this point.
There are a lot of drivers to fix first. This is just one trivial example


I agree. This thread's too full of people calling this outb method a dumb 
hack. It's a well-known legacy PC thing and while in practice the udelay 
might be a functional replacement for a majority of cases (save the races 
you are finding) a delay proportional to the bus speed makes great sense 
certainly when talking to hardware that itself runs proportinal to the bus 
speed for example.


So, really, how about just sticking in this minimal version for now? Only 
switches the port to 0xed based on DMI and is all that is needed to fix the 
actual problem. This should be minimal and no-risk enough that it could also 
go to .24 if people want it to. It'll fix a few HP laptops (I'll try and 
get/verify the dv6000z DMI strings as well).


Ingo?

Signed-off-by: Rene Herman [EMAIL PROTECTED]
commit e5f4d11c2470550500e8d8b798d902f2fe07b5c4
Author: Rene Herman [EMAIL PROTECTED]
Date:   Mon Dec 17 21:23:55 2007 +0100

x86: provide a DMI based port 0x80 I/O delay override.

Certain (HP) laptops experience trouble from our port 0x80 I/O delay
writes. This patch provides for a DMI based switch to the alternate
diagnostic port 0xed (as used by some BIOSes as well) for these.

David P. Reed confirmed that port 0xed works for him and provides a
proper delay. The symptoms of _not_ working are a hanging machine,
with hwclock use being a direct trigger.

Earlier versions of this attempted to simply use udelay(2), with the
2 being a value tested to be a nicely conservative upper-bound with
help from many on the linux-kernel mailinglist, but that approach has
two problems.

First, pre-loops_per_jiffy calibration (which is post PIT init while
some implementations of the PIT are actually one of the historically
problematic devices that need the delay) udelay() isn't particularly
well-defined. We could initialise loops_per_jiffy conservatively (and
based on CPU family so as to not unduly delay old machines) which
would sort of work, but still leaves:

Second, delaying isn't the only effect that a write to port 0x80 has.
It's also a PCI posting barrier which some devices may be explicitly
or implicitly relying on. Alan Cox did a survey and found evidence
that additionally various drivers are racy on SMP without the bus
locking outb.

Switching to an inb() makes the timing too unpredictable and as such,
this DMI based switch should be the safest approach for now. Any more
invasive changes should get more rigid testing first. It's moreover
only very few machines with the problem and a DMI based hack seems
to fit that situation.

This does not change the io_delay() in the boot code which is using
the same port 0x80 I/O delay but those do not appear to be a problem
as tested by David P. Reed. He moreover reported that booting with
acpi=off also fixed things and seeing as how ACPI isn't touched
until after this DMI based I/O port switch leaving the ones in the
boot code be is safe.

The DMI strings from David's HP Pavilion dv9000z are in there already
and we need to get/verify the DMI info from other machines with the
problem, notably the HP Pavilion dv6000z.

This patch is partly based on earlier patches from Pavel Machek and
David P. Reed.

Signed-off-by: Rene Herman [EMAIL PROTECTED]

diff --git a/arch/x86/boot/compressed/misc_32.c 
b/arch/x86/boot/compressed/misc_32.c
index b74d60d..288e162 100644
--- a/arch/x86/boot/compressed/misc_32.c
+++ b/arch/x86/boot/compressed/misc_32.c
@@ -276,10 +276,10 @@ static void putstr(const char *s)
RM_SCREEN_INFO.orig_y = y;
 
pos = (x + cols * y) * 2;   /* Update cursor position */
-   outb_p(14, vidport);
-   outb_p(0xff  (pos  9), vidport+1);
-   outb_p(15, vidport);
-   outb_p(0xff  (pos  1), vidport+1);
+   outb(14, vidport);
+   outb(0xff  (pos  9), vidport+1);
+   outb(15, vidport);
+   outb(0xff  (pos  1), vidport+1);
 }
 
 static void* memset(void* s, int c, unsigned n)
diff --git a/arch/x86/boot/compressed/misc_64.c 
b/arch/x86/boot/compressed/misc_64.c
index 6ea015a..43e5fcc 100644
--- a/arch/x86/boot/compressed/misc_64.c
+++ b/arch/x86/boot/compressed/misc_64.c
@@ -269,10 +269,10 @@ static void putstr(const char *s)
RM_SCREEN_INFO.orig_y = y;
 
pos = (x + cols * y) * 2;   /* Update cursor position */
-   outb_p(14, vidport);
-   outb_p(0xff  (pos  9), vidport+1);
-   outb_p(15, vidport);
-   outb_p(0xff  (pos  1), vidport+1);
+   outb(14, vidport);
+   outb(0xff  (pos  9), vidport+1);
+   outb(15, vidport);
+   outb(0xff  (pos  1), vidport+1);
 }
 
 static void* memset(void* s, int c, unsigned n)
diff --git

Re: [PATCH] arch/ppc/: Spelling fixes

2007-12-17 Thread Joe Perches

On Mon, 2007-12-17 at 23:42 +0300, Vitaly Bordug wrote:
 I'm not really sure we should still care about typos in
 arch/ppc..

Fine by me.  I heard tell of a desire to integrate or
rework the power/ppc arches anyway.  cheers, Joe

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH]: Atmel Serial Console interrupt handler splitup

2007-12-17 Thread Remy Bohmer

Hello Haavard,

 I'll give it a shot, but first I have some comments on your other
 patches.

Good news someone is working on this bug again. Also good news you
already found a bug in there.

 Btw, it would be nice if patches that affect more or less
 architecture-independent drivers were posted to linux-kernel (added to
 Cc.)

Not really architecture independant, I believe, because thos are
drivers for peripherals _inside_ Atmel Cores ;-)

 Also, it would be easier to review if you posted just one patch per
 e-mail. I'm going to cut  paste a bit from your attachments.

I know, but I have some troubles to get 'quilt mail' to work from
behind a proxy server, and attaching to a mail, at least it does not
corrupt the contents of the patches.

  4) For RT only: atmel_serial_irqf_nodelay.patch can be applied
  anywhere after 1 and 2

 I'll ignore this for now.

OK.

  +#define lread(port)  __raw_readl(port)
  +#define lwrite(v, port)  __raw_writel(v, port)

 Why is this necessary, and what does 'l' stand for?

There is a huge list of macros below these definitions. By doing it
this way, the macros still fit on 80 characters wide, while without
them, I had split up the macros over several lines, which does not
make it more readable. That's all.
'l' refers at the last letter of __raw_readl, and writel. Nothing special.


  - struct uart_portuart;   /* uart */
  - struct clk  *clk;   /* uart clock */
  - unsigned short  suspended;  /* is port suspended? */
  - int break_active;   /* break being received */
  + struct uart_portuart;   /* uart */
  + struct clk  *clk;   /* uart clock */
  + unsigned short  suspended;  /* is port suspended? */
  + int break_active;   /* break being received */

 Looks like you're adding one or more spaces before each TAB here. Why
 is that an improvement?

I used scripts/Lindent to reformat the file, and then I removed the
quirks Lindent put in the file. Apparantly I missed that one.

 These conflict with David Brownell's atmel_serial build warnings
 begone patch which was merged into mainline a few weeks ago.

Hmm, I seem to have missed that one. Why is it not there in a
big-AT91-patch from Andrew?

   /*
  + * receive interrupt handler.
  + */
  +static inline void
  +atmel_handle_receive(struct uart_port *port, unsigned int pending)

 Please drop inline here. The compiler will do it automatically if it
 has only one caller, and if it at some point gets several callers, we
 might not want to inline it after all.

Funny, This was the first thing that Andrew started complaining about.
He suggested to put an inline there which I had not. I already
mentioned that this was against the CodingStyle, but I also mentioned
that I did not wanted to start a fight about this :-)
So, to prevent a discussion, I added the inline...

  @@ -422,7 +454,9 @@ static int atmel_startup(struct uart_por
/*
 * Allocate the IRQ
 */
  - retval = request_irq(port-irq, atmel_interrupt, IRQF_SHARED, 
  atmel_serial, port);
  + retval =
  + request_irq(port-irq, atmel_interrupt, IRQF_SHARED,
  + atmel_serial, port);

 I think request_irq() belongs on the same line as retval =.

I blame scripts/Lindent ;-)

 Please use TABs, not spaces. Might as well remove those comments...they
 don't seem all that useful.

Go ahead...

I did not remove any comment, even if they appear useless to me. I am
not the maintainer of this driver, and just wanted to improve it, so
that it was able of running on Preempt-RT.
Before being able to submit the change that really mattered to me, I
had to make the driver pass the scripts/checkpatch.pl check, otherwise
the patch-that-matters would be completely unreadable.


  + while (!(UART_GET_CSR(port)  ATMEL_US_TXEMPTY))
  + barrier();

 Should probably use cpu_relax(), but it's probably out of scope for a
 codingstyle cleanup patch (and I don't think it matters on AVR32 or
 ARM.)

Agree.

/*
  -  *  First, save IMR and then disable interrupts
  +  *  First, save IMR and then disable interrupts
 */
imr = UART_GET_IMR(port);   /* get interrupt mask */
UART_PUT_IDR(port, ATMEL_US_RXRDY | ATMEL_US_TXRDY);
  @@ -790,30 +828,32 @@ static void atmel_console_write(struct c
uart_console_write(port, s, count, atmel_console_putchar);
 
/*
  -  *  Finally, wait for transmitter to become empty
  -  *  and restore IMR
  +  *  Finally, wait for transmitter to become empty
  +  *  and restore IMR
 */

 Looks like you're replacing TABs with spaces. Why?



  -// TODO: CR is a write-only register
  -//   unsigned int cr;
  +/* TODO: CR is a write-only register
  +//  unsigned int cr;
   //
  -//   cr = UART_GET_CR(port)

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

2007-12-17 Thread H. Peter Anvin


Rene Herman wrote:

On 17-12-07 17:12, Alan Cox wrote:


I don't think we should be offering udelay based delays at this point.
There are a lot of drivers to fix first. This is just one trivial example


I agree. This thread's too full of people calling this outb method a 
dumb hack. It's a well-known legacy PC thing and while in practice the 
udelay might be a functional replacement for a majority of cases (save 
the races you are finding) a delay proportional to the bus speed makes 
great sense certainly when talking to hardware that itself runs 
proportinal to the bus speed for example.


So, really, how about just sticking in this minimal version for now? 
Only switches the port to 0xed based on DMI and is all that is needed to 
fix the actual problem. This should be minimal and no-risk enough that 
it could also go to .24 if people want it to. It'll fix a few HP laptops 
(I'll try and get/verify the dv6000z DMI strings as well).




I think retaining the command-line option available is a good thing, 
though.  If nothing else, it is something very quick we can ask other 
people to try if they seem to have similar problems.


Other than that, this alternate-port patch is a low-impact patch not 
affecting hardware not on the blacklist, which makes it appropriate for 
2.6.24 IMO.


-hpa
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: /dev/urandom uses uninit bytes, leaks user data

2007-12-17 Thread David Schwartz


 The bottom line:  At a cost of at most three unpredictable branches
 (whether to clear the bytes in the last word with indices congruent
 to 1, 2, or 3 modulo 4), then the code can reduce the risk from something
 small but positive, to zero.  This is very inexpensive insurance.

 John Reiser, [EMAIL PROTECTED]

Even if you're right, the change isn't free. You've simply presented
evidence of one non-zero benefit of it. You've given no ability to assess
the size of this benefit and no way to figure if it exceeds the cost. There
is also a non-zero *security* cost to this change.

DS


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.24-rc5: tape drive not responding

2007-12-17 Thread John Stoffel


Just to confirm, the propsed patch to st.c fixes the issue with
2.6.24-rc5 as well at 2.6.24-rc5-mm1 with access to my DLT tape
drives.

Thanks!
John
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

2007-12-17 Thread David P. Reed




H. Peter Anvin wrote:

David P. Reed wrote:
As support: port 80 on the reporter's (my) HP dv9000z laptop clearly 
responds to reads differently than unused ports.  In particular, an 
inb takes 1/2 the elapsed time compared to a read to known unused 
port 0xed - 792 tsc ticks for port 80 compared to about 1450 tsc 
ticks for port 0xed and other unused ports (tsc at 800 MHz).




Any timings for port 0xf0 (write zero), out of curiosity?



Here's a bunch of data:

port 0xF0: cycles: out 919, in 933
port 0xed: cycles: out 2541, in 2036
port 0x70: cycles: out n/a,  in 934
port 0x80: cycles: out 1424, in 795

AMD Turion 64x2 TL-60 CPU running at 800 MHz, nVidia MCP51 chipset, 
Quanta motherboard.  Running 2.6.24-rc5 with Ingo's patch so inb_p, etc. 
use port 0xed.


Note that I can run the port 80 test once, the second time I get the 
hard freeze.  I didn't try writing to port 70 from userspace - that 
one's dangerous, but the reading of it was included for a timing typical 
of a chipset supported device.  These are all pretty consistent.


I find the read timing from 0x80 very interesting.  The write 
timeing is also interesting, being faster than an unused port. 



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.

2007-12-17 Thread Rene Herman


On 15-12-07 00:29, Alan Cox wrote:


?? Just initialize bogomips to 6GHz equivalent... and we are fine
until 6GHz cpus come out.

How long will that take to boot on a 386?


Well the dumb approach to fix that would seem to be to initialise it to

cpu-family   3 - 50MHz 4 - 300Mhz 5- etc...


By the way, you have a 300 MHz 486? I believe 3 - 40, 4 - 133, 5 - 233 
would be good? And I'm not really sure about the etc. P6 has a large range 
again...


Rene.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net/sctp/: Spelling fixes

2007-12-17 Thread Vlad Yasevich

Joe Perches wrote:
 Signed-off-by: Joe Perches [EMAIL PROTECTED]

Thanks...  I am surprised this is all you found :)

ACK.

-vlad

 ---
  net/sctp/sm_make_chunk.c |8 
  1 files changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
 index f487629..ed7c9e3 100644
 --- a/net/sctp/sm_make_chunk.c
 +++ b/net/sctp/sm_make_chunk.c
 @@ -286,7 +286,7 @@ struct sctp_chunk *sctp_make_init(const struct 
 sctp_association *asoc,
  
   sctp_addto_chunk(retval, sizeof(ecap_param), ecap_param);
  
 - /* Add the supported extensions paramter.  Be nice and add this
 + /* Add the supported extensions parameter.  Be nice and add this
* fist before addiding the parameters for the extensions themselves
*/
   if (num_ext) {
 @@ -2859,7 +2859,7 @@ struct sctp_chunk *sctp_process_asconf(struct 
 sctp_association *asoc,
   chunk_len -= length;
  
   /* Skip the address parameter and store a pointer to the first
 -  * asconf paramter.
 +  * asconf parameter.
*/
   length = ntohs(addr_param-v4.param_hdr.length);
   asconf_param = (sctp_addip_param_t *)((void *)addr_param + length);
 @@ -2868,7 +2868,7 @@ struct sctp_chunk *sctp_process_asconf(struct 
 sctp_association *asoc,
   /* create an ASCONF_ACK chunk.
* Based on the definitions of parameters, we know that the size of
* ASCONF_ACK parameters are less than or equal to the twice of ASCONF
 -  * paramters.
 +  * parameters.
*/
   asconf_ack = sctp_make_asconf_ack(asoc, serial, chunk_len * 2);
   if (!asconf_ack)
 @@ -3062,7 +3062,7 @@ int sctp_process_asconf_ack(struct sctp_association 
 *asoc,
   asconf_len -= length;
  
   /* Skip the address parameter in the last asconf sent and store a
 -  * pointer to the first asconf paramter.
 +  * pointer to the first asconf parameter.
*/
   length = ntohs(addr_param-v4.param_hdr.length);
   asconf_param = (sctp_addip_param_t *)((void *)addr_param + length);

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 2/3] PCI: use dev_printk in quirk messages

2007-12-17 Thread bjorn . helgaas

Convert quirk printks to dev_printk().

I made the MSI disable messages a little more consistent:

- always use disabled, not deactivated
- specify device MSI disabled or subordinate MSI disabled when
  disabling MSI for only a specific device or subordinate bus

Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED]

---
 drivers/pci/quirks.c  |  110 +++---
 drivers/usb/host/pci-quirks.c |   13 +---
 2 files changed, 56 insertions(+), 67 deletions(-)

Index: w/drivers/pci/quirks.c
===
--- w.orig/drivers/pci/quirks.c 2007-12-17 14:09:03.0 -0700
+++ w/drivers/pci/quirks.c  2007-12-17 14:09:13.0 -0700
@@ -47,7 +47,7 @@
while ((d = pci_get_device(PCI_VENDOR_ID_INTEL, 
PCI_DEVICE_ID_INTEL_82371SB_0, d))) {
pci_read_config_byte(d, 0x82, dlc);
if (!(dlc  11)) {
-   printk(KERN_ERR PCI: PIIX3: Enabling Passive Release 
on %s\n, pci_name(d));
+   dev_err(d-dev, PIIX3: Enabling Passive Release\n);
dlc |= 11;
pci_write_config_byte(d, 0x82, dlc);
}
@@ -69,7 +69,7 @@
 {
if (!isa_dma_bridge_buggy) {
isa_dma_bridge_buggy=1;
-   printk(KERN_INFO Activating ISA DMA hang workarounds.\n);
+   dev_info(dev-dev, Activating ISA DMA hang workarounds\n);
}
 }
/*
@@ -93,7 +93,7 @@
 static void __devinit quirk_nopcipci(struct pci_dev *dev)
 {
if ((pci_pci_problems  PCIPCI_FAIL)==0) {
-   printk(KERN_INFO Disabling direct PCI/PCI transfers.\n);
+   dev_info(dev-dev, Disabling direct PCI/PCI transfers\n);
pci_pci_problems |= PCIPCI_FAIL;
}
 }
@@ -106,7 +106,7 @@
pci_read_config_byte(dev, 0x08, rev);
if (rev == 0x13) {
/* Erratum 24 */
-   printk(KERN_INFO Chipset erratum: Disabling direct PCI/AGP 
transfers.\n);
+   dev_info(dev-dev, Chipset erratum: Disabling direct PCI/AGP 
transfers\n);
pci_pci_problems |= PCIAGP_FAIL;
}
 }
@@ -118,7 +118,7 @@
 static void __devinit quirk_triton(struct pci_dev *dev)
 {
if ((pci_pci_problemsPCIPCI_TRITON)==0) {
-   printk(KERN_INFO Limiting direct PCI/PCI transfers.\n);
+   dev_info(dev-dev, Limiting direct PCI/PCI transfers\n);
pci_pci_problems |= PCIPCI_TRITON;
}
 }
@@ -181,7 +181,7 @@
busarb = ~(15);
busarb |= (14);
pci_write_config_byte(dev, 0x76, busarb);
-   printk(KERN_INFO Applying VIA southbridge workaround.\n);
+   dev_info(dev-dev, Applying VIA southbridge workaround\n);
 exit:
pci_dev_put(p);
 }
@@ -199,7 +199,7 @@
 static void __devinit quirk_viaetbf(struct pci_dev *dev)
 {
if ((pci_pci_problemsPCIPCI_VIAETBF)==0) {
-   printk(KERN_INFO Limiting direct PCI/PCI transfers.\n);
+   dev_info(dev-dev, Limiting direct PCI/PCI transfers\n);
pci_pci_problems |= PCIPCI_VIAETBF;
}
 }
@@ -208,7 +208,7 @@
 static void __devinit quirk_vsfx(struct pci_dev *dev)
 {
if ((pci_pci_problemsPCIPCI_VSFX)==0) {
-   printk(KERN_INFO Limiting direct PCI/PCI transfers.\n);
+   dev_info(dev-dev, Limiting direct PCI/PCI transfers\n);
pci_pci_problems |= PCIPCI_VSFX;
}
 }
@@ -223,7 +223,7 @@
 static void __init quirk_alimagik(struct pci_dev *dev)
 {
if ((pci_pci_problemsPCIPCI_ALIMAGIK)==0) {
-   printk(KERN_INFO Limiting direct PCI/PCI transfers.\n);
+   dev_info(dev-dev, Limiting direct PCI/PCI transfers\n);
pci_pci_problems |= PCIPCI_ALIMAGIK|PCIPCI_TRITON;
}
 }
@@ -237,7 +237,7 @@
 static void __devinit quirk_natoma(struct pci_dev *dev)
 {
if ((pci_pci_problemsPCIPCI_NATOMA)==0) {
-   printk(KERN_INFO Limiting direct PCI/PCI transfers.\n);
+   dev_info(dev-dev, Limiting direct PCI/PCI transfers\n);
pci_pci_problems |= PCIPCI_NATOMA;
}
 }
@@ -293,7 +293,7 @@
pcibios_bus_to_resource(dev, res, bus_region);
 
pci_claim_resource(dev, nr);
-   printk(PCI quirk: region %04x-%04x claimed by %s\n, region, 
region + size - 1, name);
+   dev_info(dev-dev, quirk: region %04x-%04x claimed by %s\n, 
region, region + size - 1, name);
}
 }  
 
@@ -303,7 +303,7 @@
  */
 static void __devinit quirk_ati_exploding_mce(struct pci_dev *dev)
 {
-   printk(KERN_INFO ATI Northbridge, reserving I/O ports 0x3b0 to 
0x3bb.\n);
+   dev_info(dev-dev, ATI Northbridge, reserving I/O ports 0x3b0 to 
0x3bb\n);
/* Mae rhaid i ni beidio ag edrych ar y lleoliadiau I/O hyn */
request_region(0x3b0, 0x0C, RadeonIGP);
request_region(0x3d3, 0x01, RadeonIGP);
@@ -355,7

[patch 1/3] PCI: print quirk name in debug messages

2007-12-17 Thread bjorn . helgaas

Instead of printing this:

PCI: Calling quirk c023b250 for :00:00.0

we can print this:

pci :00:00.0: calling quirk 0xc023b270: quirk_cardbus_legacy+0x0/0x30()

The address is superfluous because sprint_symbol() includes the
address if the symbol lookup fails, but this is the same style used
in do_initcalls() and pnp_fixup_device().

Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED]

Index: w/drivers/pci/quirks.c
===
--- w.orig/drivers/pci/quirks.c 2007-12-17 14:09:01.0 -0700
+++ w/drivers/pci/quirks.c  2007-12-17 14:09:03.0 -0700
@@ -21,6 +21,7 @@
 #include linux/init.h
 #include linux/delay.h
 #include linux/acpi.h
+#include linux/kallsyms.h
 #include pci.h
 
 /* The Mellanox Tavor device gives false positive parity errors
@@ -1479,7 +1480,11 @@
while (f  end) {
if ((f-vendor == dev-vendor || f-vendor == (u16) PCI_ANY_ID) 

(f-device == dev-device || f-device == (u16) 
PCI_ANY_ID)) {
-   pr_debug(PCI: Calling quirk %p for %s\n, f-hook, 
pci_name(dev));
+#ifdef DEBUG
+   dev_dbg(dev-dev, calling quirk 0x%p, f-hook);
+   print_fn_descriptor_symbol(: %s()\n,
+   (unsigned long) f-hook);
+#endif
f-hook(dev);
}
f++;

--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers/net/: Spelling fixes

2007-12-17 Thread Joe Perches

On Mon, 2007-12-17 at 21:56 +0100, Stefano Brivio wrote:
 On Mon, 17 Dec 2007 11:40:08 -0800
 Joe Perches [EMAIL PROTECTED] wrote:
  diff --git a/drivers/net/ucc_geth_ethtool.c
 b/drivers/net/ucc_geth_ethtool.c
  index 9a9622c..f8d319b 100644
  --- a/drivers/net/ucc_geth_ethtool.c
  +++ b/drivers/net/ucc_geth_ethtool.c
  @@ -7,7 +7,7 @@
*
* Limitation: 
* Can only get/set setttings of the first queue.
  ^^^

Good eyes...  Unrelated to what I changed too.
cheers, Joe

Signed-off-by: Joe Perches [EMAIL PROTECTED]
---
diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c
index 121cb10..cdfb2b0 100644
--- a/drivers/net/s2io.c
+++ b/drivers/net/s2io.c
@@ -6823,8 +6823,8 @@ static void do_s2io_card_down(struct s2io_nic * sp, int 
do_io)
while(do_io) {
/* As per the HW requirement we need to replenish the
 * receive buffer to avoid the ring bump. Since there is
-* no intention of processing the Rx frame at this pointwe are
-* just settting the ownership bit of rxd in Each Rx
+* no intention of processing the Rx frame at this point we are
+* just setting the ownership bit of rxd in each Rx
 * ring to HW and set the appropriate buffer size
 * based on the ring mode
 */
diff --git a/drivers/net/ucc_geth_ethtool.c b/drivers/net/ucc_geth_ethtool.c
index f8d319b..3e50df8 100644
--- a/drivers/net/ucc_geth_ethtool.c
+++ b/drivers/net/ucc_geth_ethtool.c
@@ -6,7 +6,7 @@
  * Author: Li Yang [EMAIL PROTECTED]
  *
  * Limitation: 
- * Can only get/set setttings of the first queue.
+ * Can only get/set settings of the first queue.
  * Need to re-open the interface manually after changing some parameters.
  *
  * This program is free software; you can redistribute  it and/or modify it


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: slab quirks in DEBUG, ctor, and initialization

2007-12-17 Thread John Reiser

Hi Pekka,

In mm/slab.c, the DEBUG variant of cache_alloc_debugcheck_after
might call  cachep-ctor(objp, cachep, 0);  but the non-DEBUG
variant does absolutely nothing.  idr_pre_get is a routine
which notices the difference.
 
 
 How does ipr_pre_get notice this?

idr_pre_get calls kmem_cache_alloc, which constructs 'struct idr_layer'
via the cachep-ctor() call from cache_alloc_debugcheck_after to
idr_cache_ctor, and not via cache_init_objs.  So if DEBUG is off,
then idr_cache_ctor does not get its chance to call memset,
which could leave the struct idr_layer potentially undefined.

Even when cache_alloc_debugcheck_after does invoke the ctor,
then it is conditional upon  cachep-flags  SLAB_POISON.  This
assumes that the only two states are poisoned and all-zero
(from .bss static, or via a cleared new page frame.)
So if SLAB_POISON is not specified, then a ctor which
does anything other than memset(,0,) is out of luck.
Instead: if a ctor is specified then it should be called
for each successful allocation.
 
 
 Sorry, I don't understand at all what's the problem is here. For the
 common (non-poison) case, we initialize all objects *once* whenever a
 cache is grown (see cache_grow calling cache_init_objs) which is the
 whole point of having constructors. When poisoning is enabled, we
 obviously cannot do this which is why we call the constructor for
 every allocation.

There is a comment near the beginning of mm/slab.c:
 * This means, that your constructor is used only for newly allocated
 * slabs and you must pass objects with the same initializations to
 * kmem_cache_free.
Note that the comment should be updated to account for the constructor
also being called if SLAB_POISON is specified.  A significant implication
is that calling the constructor always establishes good state, even
though the call might not be necessary, and although it might take
more time than not calling it.

In order to avoid the allocator having to call the constructor, then the
caller of kmem_cache_free must call the constructor just before freeing,
or establish the same values.  In contrast to calling the constructor
every time, the existing convention increases complexity and risk of bugs,
in exchange for faster performance when actions equivalent to the ctor
are performed in the dtor instead, or when state that is equivalent to
the ctor occurs as a natural byproduct of being done with the object.

The real gripe is that the current code makes it cumbersome for a
dynamic checking program such as valgrind(memcheck) to record correctly
the state of the object.  Is the object initialized (and which parts
of it, and were the initializations performed into allocated space),
or is it merely allocated and uninitialized?

-- 
John Reiser, [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

2007-12-17 Thread H. Peter Anvin


David P. Reed wrote:


Note that I can run the port 80 test once, the second time I get the 
hard freeze.  I didn't try writing to port 70 from userspace - that 
one's dangerous, but the reading of it was included for a timing typical 
of a chipset supported device.  These are all pretty consistent.


I find the read timing from 0x80 very interesting.  The write 
timeing is also interesting, being faster than an unused port.




Once again: reading from port 0x80 goes to the DMA page device.

-hpa
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 3/3] PCI: use dev_printk in x86 quirk messages

2007-12-17 Thread bjorn . helgaas

Convert quirk printks to dev_printk().

Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED]

---
 arch/x86/kernel/quirks.c |   42 ++
 arch/x86/pci/fixup.c |   22 +++---
 2 files changed, 33 insertions(+), 31 deletions(-)

Index: w/arch/x86/kernel/quirks.c
===
--- w.orig/arch/x86/kernel/quirks.c 2007-12-17 13:56:46.0 -0700
+++ w/arch/x86/kernel/quirks.c  2007-12-17 14:09:18.0 -0700
@@ -30,8 +30,8 @@
raw_pci_ops-read(0, 0, 0x40, 0x4c, 2, word);
 
if (!(word  (1  13))) {
-   printk(KERN_INFO Intel E7520/7320/7525 detected. 
-   Disabling irq balancing and affinity\n);
+   dev_info(dev-dev, Intel E7520/7320/7525 detected; 
+   disabling irq balancing and affinity\n);
 #ifdef CONFIG_IRQBALANCE
irqbalance_disable();
 #endif
@@ -104,14 +104,16 @@
pci_read_config_dword(dev, 0xF0, rcba);
rcba = 0xC000;
if (rcba == 0) {
-   printk(KERN_DEBUG RCBA disabled. Cannot force enable HPET\n);
+   dev_printk(KERN_DEBUG, dev-dev, RCBA disabled; 
+   cannot force enable HPET\n);
return;
}
 
/* use bits 31:14, 16 kB aligned */
rcba_base = ioremap_nocache(rcba, 0x4000);
if (rcba_base == NULL) {
-   printk(KERN_DEBUG ioremap failed. Cannot force enable HPET\n);
+   dev_printk(KERN_DEBUG, dev-dev, ioremap failed; 
+   cannot force enable HPET\n);
return;
}
 
@@ -122,8 +124,8 @@
/* HPET is enabled in HPTC. Just not reported by BIOS */
val = val  0x3;
force_hpet_address = 0xFED0 | (val  12);
-   printk(KERN_DEBUG Force enabled HPET at base address 0x%lx\n,
-  force_hpet_address);
+   dev_printk(KERN_DEBUG, dev-dev, Force enabled HPET at 
+   0x%lx\n, force_hpet_address);
iounmap(rcba_base);
return;
}
@@ -142,11 +144,12 @@
if (err) {
force_hpet_address = 0;
iounmap(rcba_base);
-   printk(KERN_DEBUG Failed to force enable HPET\n);
+   dev_printk(KERN_DEBUG, dev-dev,
+   Failed to force enable HPET\n);
} else {
force_hpet_resume_type = ICH_FORCE_HPET_RESUME;
-   printk(KERN_DEBUG Force enabled HPET at base address 0x%lx\n,
-  force_hpet_address);
+   dev_printk(KERN_DEBUG, dev-dev, Force enabled HPET at 
+   0x%lx\n, force_hpet_address);
}
 }
 
@@ -206,8 +209,8 @@
if (val  0x4) {
val = 0x3;
force_hpet_address = 0xFED0 | (val  12);
-   printk(KERN_DEBUG HPET at base address 0x%lx\n,
-  force_hpet_address);
+   dev_printk(KERN_DEBUG, dev-dev, HPET at 0x%lx\n,
+   force_hpet_address);
return;
}
 
@@ -227,14 +230,14 @@
/* HPET is enabled in HPTC. Just not reported by BIOS */
val = 0x3;
force_hpet_address = 0xFED0 | (val  12);
-   printk(KERN_DEBUG Force enabled HPET at base address 0x%lx\n,
-  force_hpet_address);
+   dev_printk(KERN_DEBUG, dev-dev, Force enabled HPET at 
+   0x%lx\n, force_hpet_address);
cached_dev = dev;
force_hpet_resume_type = OLD_ICH_FORCE_HPET_RESUME;
return;
}
 
-   printk(KERN_DEBUG Failed to force enable HPET\n);
+   dev_printk(KERN_DEBUG, dev-dev, Failed to force enable HPET\n);
 }
 
 /*
@@ -292,8 +295,8 @@
 */
if (val  0x80) {
force_hpet_address = (val  ~0x3ff);
-   printk(KERN_DEBUG HPET at base address 0x%lx\n,
-  force_hpet_address);
+   dev_printk(KERN_DEBUG, dev-dev, HPET at 0x%lx\n,
+   force_hpet_address);
return;
}
 
@@ -307,14 +310,14 @@
pci_read_config_dword(dev, 0x68, val);
if (val  0x80) {
force_hpet_address = (val  ~0x3ff);
-   printk(KERN_DEBUG Force enabled HPET at base address 0x%lx\n,
-  force_hpet_address);
+   dev_printk(KERN_DEBUG, dev-dev, Force enabled HPET at 
+   0x%lx\n, force_hpet_address);
cached_dev = dev;
force_hpet_resume_type = VT8237_FORCE_HPET_RESUME;
return;
}
 
-   printk(KERN_DEBUG Failed to force enable HPET\n);
+   dev_printk(KERN_DEBUG, dev-dev, Failed to force enable HPET\n);
 }

Re: 1st version of azfs

2007-12-17 Thread Bodo Eggert

Maxim Shchetynin [EMAIL PROTECTED] wrote:

 +config AZ_FS
 +tristate AZFS filesystem support
 +default m
   ^
STRONG NACK, I hate digging in the menu tree and hunting for things I
don't need.

 +help
 +  Non-buffered filesystem for block devices with a gendisk and
 +  with direct_access() method in gendisk-fops.
 +  AZFS does not buffer outgoing traffic and is doing no read
 ahead.
 +  AZFS uses block-size and sector-size provided by block
 device
 +  and gendisk's queue. Though mmap() method is available only
 if
 +  block-size equals to or is greater than system page size.

What is the benefit or intended use of this filesystem? Will your intended
user say gendisk-fops-direct_access? I wanted to use it all my life?

AZFZ seems to be an acronym. AirZound File System?
http://globetrotter.de/de/shop/detail.php?mod_nr=ex_35001GTID=7c553060901a873c5bd29a1846ff39a3a32


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 0/3] use dev_printk in PCI quirks

2007-12-17 Thread bjorn . helgaas

No functional changes here; these only use dev_printk when possible.
In a few cases, I tweaked message wordings to make them more consistent.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/4] x86: fix jprobe_saved_sp handling

2007-12-17 Thread Harvey Harrison

This patch fixes a bug of jprobe and cleans up. jprobe for x86-64
can cause kernel page fault when the jprobe_return() is called from
incorrect function. Anyway, that path finally invokes BUG() macro,
so this is not so serious.

Based on patch from Masami Hiramatsu [EMAIL PROTECTED]

- Use jprobe_saved_regs instead getting it from stack.
  (Especially on x86-64, it may get incorrect data, because
   pt_regs can not be get by using container_of(rsp))
- Change the type of stack pointer to unsigned long *.

Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
 arch/x86/kernel/kprobes.c |8 ++--
 include/asm-x86/kprobes.h |2 +-
 2 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/kprobes.c b/arch/x86/kernel/kprobes.c
index e5b7d07..9130c01 100644
--- a/arch/x86/kernel/kprobes.c
+++ b/arch/x86/kernel/kprobes.c
@@ -1022,16 +1022,12 @@ int __kprobes longjmp_break_handler(struct kprobe *p, 
struct pt_regs *regs)
if ((addr  (u8 *) jprobe_return)  (addr  (u8 *) jprobe_return_end)) 
{
 #ifdef CONFIG_X86_32
if (regs-sp != kcb-jprobe_saved_sp) {
-   struct pt_regs *saved_regs =
-   container_of(kcb-jprobe_saved_sp,
-   struct pt_regs, sp);
+   struct pt_regs *saved_regs = kcb-jprobe_saved_sp;
printk(current sp %p does not match saved sp %p\n,
   regs-sp, kcb-jprobe_saved_sp);
 #else
if ((long *)regs-sp != kcb-jprobe_saved_sp) {
-   struct pt_regs *saved_regs =
-   container_of(kcb-jprobe_saved_sp,
-   struct pt_regs, sp);
+   struct pt_regs *saved_regs = kcb-jprobe_saved_sp;
printk(current sp %p does not match saved sp %p\n,
   (long *)regs-sp, kcb-jprobe_saved_sp);
 #endif
diff --git a/include/asm-x86/kprobes.h b/include/asm-x86/kprobes.h
index e348ed6..7319c62 100644
--- a/include/asm-x86/kprobes.h
+++ b/include/asm-x86/kprobes.h
@@ -79,7 +79,7 @@ struct kprobe_ctlblk {
unsigned long kprobe_status;
unsigned long kprobe_old_flags;
unsigned long kprobe_saved_flags;
-   long *jprobe_saved_sp;
+   unsigned long *jprobe_saved_sp;
struct pt_regs jprobe_saved_regs;
kprobe_opcode_t jprobes_stack[MAX_STACK_SIZE];
struct prev_kprobe prev_kprobe;
-- 
1.5.4.rc0.1083.gf568


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/4] x86: add kprobe-booster to X86_64

2007-12-17 Thread Harvey Harrison

Based on X86_32, mostly by un-ifdeffing code.

Based on patch from Masami Hiramatsu [EMAIL PROTECTED]

Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
 arch/x86/kernel/kprobes.c |   57 +++--
 include/asm-x86/kprobes.h |   12 +
 2 files changed, 36 insertions(+), 33 deletions(-)

diff --git a/arch/x86/kernel/kprobes.c b/arch/x86/kernel/kprobes.c
index 64c702c..47bae2c 100644
--- a/arch/x86/kernel/kprobes.c
+++ b/arch/x86/kernel/kprobes.c
@@ -151,15 +151,17 @@ twobyte_has_modrm[256 / (sizeof(unsigned long) * 8)] = {
 #undef R4
 #undef RF
 
-/* insert a jmp code */
+/*
+ * Insert a jump instruction at address 'from' which jumps to address 'to' */
 static inline void set_jmp_op(void *from, void *to)
 {
struct __arch_jmp_op {
char op;
-   long raddr;
-   } __attribute__((packed)) *jop;
+   s32 raddr;
+   } __attribute__((packed)) * jop;
jop = (struct __arch_jmp_op *)from;
-   jop-raddr = (long)(to) - ((long)(from) + 5);
+
+   jop-raddr = (s32)((long)(to) - ((long)(from) + 5));
jop-op = RELATIVEJUMP_INSTRUCTION;
 }
 
@@ -183,6 +185,9 @@ retry:
}
 
switch (opcode  0xf0) {
+#ifdef X86_64
+   case 0x40:
+   goto retry; /* REX prefix is boostable */
case 0x60:
if (0x63  opcode  opcode  0x67)
goto retry; /* prefixes */
@@ -202,7 +207,7 @@ retry:
case 0xf0:
if ((opcode  0x0c) == 0  opcode != 0xf1)
goto retry; /* lock/rep(ne) prefix */
-   /* clear and set flags can be boost */
+   /* clear and set flags are boostable */
return (opcode == 0xf5 || (0xf7  opcode  opcode  0xfe));
default:
if (opcode == 0x26 || opcode == 0x36 || opcode == 0x3e)
@@ -221,6 +226,10 @@ static s32 __kprobes *is_riprel(u8 *insn)
 {
int need_modrm;
 
+#ifdef CONFIG_X86_32
+   return NULL;
+#endif
+
/* Skip legacy instruction prefixes.  */
while (1) {
switch (*insn) {
@@ -266,18 +275,10 @@ static s32 __kprobes *is_riprel(u8 *insn)
 
 static void __kprobes arch_copy_kprobe(struct kprobe *p)
 {
-#ifdef CONFIG_X86_32
-   memcpy(p-ainsn.insn, p-addr,
-  (MAX_INSN_SIZE + 1) * sizeof(kprobe_opcode_t));
-   p-opcode = *p-addr;
-   if (can_boost(p-addr)) {
-   p-ainsn.boostable = 0;
-   } else {
-   p-ainsn.boostable = -1;
-   }
-#else
s32 *ripdisp;
-   memcpy(p-ainsn.insn, p-addr, MAX_INSN_SIZE);
+   memcpy(p-ainsn.insn, p-addr,
+  MAX_INSN_SIZE + sizeof(kprobe_opcode_t));
+
ripdisp = is_riprel(p-ainsn.insn);
if (ripdisp) {
/*
@@ -297,8 +298,13 @@ static void __kprobes arch_copy_kprobe(struct kprobe *p)
BUG_ON((s64) (s32) disp != disp); /* Sanity check.  */
*ripdisp = disp;
}
+
p-opcode = *p-addr;
-#endif
+   if (can_boost(p-addr)) {
+   p-ainsn.boostable = 0;
+   } else {
+   p-ainsn.boostable = -1;
+   }
 }
 
 /*
@@ -343,11 +349,7 @@ void __kprobes arch_disarm_kprobe(struct kprobe *p)
 void __kprobes arch_remove_kprobe(struct kprobe *p)
 {
mutex_lock(kprobe_mutex);
-#ifdef CONFIG_X86_32
free_insn_slot(p-ainsn.insn, (p-ainsn.boostable == 1));
-#else
-   free_insn_slot(p-ainsn.insn, 0);
-#endif
mutex_unlock(kprobe_mutex);
 }
 
@@ -544,7 +546,7 @@ static int __kprobes kprobe_handler(struct pt_regs *regs)
return 1;
 
 ss_probe:
-#if defined(CONFIG_X86_32)  (!defined(CONFIG_PREEMPT) || defined(CONFIG_PM))
+#if !defined(CONFIG_PREEMPT) || defined(CONFIG_PM)
if (p-ainsn.boostable == 1  !p-post_handler){
/* Boost up -- we can execute copied instructions directly */
reset_current_kprobe();
@@ -722,6 +724,11 @@ void *__kprobes trampoline_handler(struct pt_regs *regs)
  * that is atop the stack is the address following the copied instruction.
  * We need to make it the address following the original instruction.
  *
+ * If this is the first time we've single-stepped the instruction at
+ * this probepoint, and the instruction is boostable, boost it: add a
+ * jump instruction after the copied instruction, that jumps to the next
+ * instruction after the probepoint.
+ *
  * This function also checks instruction size for preparing direct execution.
  */
 static void __kprobes resume_execution(struct kprobe *p,
@@ -754,10 +761,8 @@ static void __kprobes resume_execution(struct kprobe *p,
case 0xcb:
case 0xcf:
case 0xea:  /* jmp absolute -- ip is correct */
-#ifdef CONFIG_X86_32
/* ip is already adjusted, no more changes required */
p-ainsn.boostable = 1;
-#endif
goto no_change;
case 0xe8:  /* call relative - Fix return addr

[PATCH 2/4] x86: kprobe cleanup resume_execution

2007-12-17 Thread Harvey Harrison

This patch cleans up and fixes bugs in resume_execution on x86-64.
Kprobes for x86-64 may cause a kernel crash if it inserted on iret
instruction.

call absolute case 0x9a is invalid on x86-64, so we don't need
treat it, leave it ifdef X86_32.

 - Add iret(0xcf) case.to X86_64
 - Fold jmp absolute (0xea) handling into iret/ret/lret handling

Based on patch from Masami Hiramatsu [EMAIL PROTECTED]

Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
 arch/x86/kernel/kprobes.c |   11 +++
 1 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/kprobes.c b/arch/x86/kernel/kprobes.c
index 9130c01..64c702c 100644
--- a/arch/x86/kernel/kprobes.c
+++ b/arch/x86/kernel/kprobes.c
@@ -748,12 +748,13 @@ static void __kprobes resume_execution(struct kprobe *p,
*tos = ~(TF_MASK | IF_MASK);
*tos |= kcb-kprobe_old_flags;
break;
-   case 0xc2:  /* ret/lret */
+   case 0xc2:  /* iret/ret/lret */
case 0xc3:
case 0xca:
case 0xcb:
+   case 0xcf:
+   case 0xea:  /* jmp absolute -- ip is correct */
 #ifdef CONFIG_X86_32
-   case 0xcf:  /* iret */
/* ip is already adjusted, no more changes required */
p-ainsn.boostable = 1;
 #endif
@@ -783,12 +784,6 @@ static void __kprobes resume_execution(struct kprobe *p,
goto no_change;
}
break;
-   case 0xea:  /* jmp absolute -- ip is correct */
-#ifdef CONFIG_X86_32
-   /* ip is already adjusted, no more changes required */
-   p-ainsn.boostable = 1;
-#endif
-   goto no_change;
default:
break;
}
-- 
1.5.4.rc0.1083.gf568


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: cpuinfo_cur_freq always max

2007-12-17 Thread Johannes Weiner

Hi Steve,

Stephen Clark [EMAIL PROTECTED] writes:

 But with 2.6.23.8-34.fc7
 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
 is always the max cpu speed of 1826000.

 While cpuinfo_cur_freq is the max 1826000 /proc/cpuinfo relflects the
 correct speed when idle of
 996000

Which governor are you using?  ondemand?

Hannes
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

2007-12-17 Thread Ingo Molnar


* David P. Reed [EMAIL PROTECTED] wrote:

 Ingo -

 I finished testing the rolled up patch that you provided.  It seems to work 
 just fine.  Thank you for putting this all together and persevering in this 
 long and complex discussion. 
 Here are the results, on the offending laptop, using 2.6.24-rc5 plus that 
 one patch.

 First: booted with normal boot parameters (no io_delay=):

According to dmesg, 0xed is used.

hwclock ran fine, hundreds of times.
my shell script loop doing cat /dev/nvram  /dev/null ran fine, 
 several times.
Running Rene's port 80 speed test ran fine once, then froze the system 
 hard.  (expected)

 Second: booted with io_delay=0x80, several tests, rebooting after freezes:

hwclock froze system hard.  (this is the problem that drove me to find 
 this bug).
my shell script loop froze system hard.

 Third: booted with io_delay=none:

hwclock ran fine, also hundreds of times.
my shell script loop ran fine several times.
Running rene's port80 test ran fine twice, froze system hard on third 
 try.

 Fourth: booted with io_delay=udelay:

hwclock ran fine, also hundreds of times.
my shell script loop ran fine several times.
Running Rene's port80 test ran fine, froze system hard on second try.

 Analysis:

patch works fine, and default to 0xed seems super conservative. I 
 will probably use the boot parameter io_delay=none, because I don't 
 seem to have any I/O
devices that require any delays - and this way I can find any that 
do.

great, and thanks for the extensive testing! I've added this line to the 
patch:

 Tested-by: David P. Reed [EMAIL PROTECTED]

if you dont mind.

Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: FInal kprobes rollup patches

2007-12-17 Thread Masami Hiramatsu

Hi Harvey,

Harvey Harrison wrote:
 On Mon, 2007-12-17 at 19:52 +0530, Srikar Dronamraju wrote:
 * Ingo Molnar [EMAIL PROTECTED] [2007-12-15 14:12:04]:


 Hi Ingo, Harvey

 In file include/asm-x86/kprobes_32.h
 typedef u8 kprobe_opcode_t;
 hence sizeof(kprobe_opcode_t) turns out to be 1.

 Hence

 memcpy(p-ainsn.insn, p-addr, MAX_INSN_SIZE * sizeof(kprobe_opcode_t));
 is correct.

 
 OK, but this would be much clearer to adopt the X86_64 way, define
 MAX_INSN_SIZE one smaller and make this line:
 
 /* Copy original instruction plus space for 1 byte relative jump */
 memcpy(p-ainsn.insn, p-addr, MAX_INSN_SIZE + sizeof(kprobe_opcode_t));

 See the first patch of my cleanup work that unified MAX_INSN_SIZE
 and you'll see why this jumped out.

 Harvey

If you mention about a relative jump which is inserted by
resume_execution(), I think you might misunderstand that relative jump.

The size of that relative jump, which will be embedded by kprobe-booster, is
5-bytes(not 1 byte). So it needs 5 bytes space.
And we decided not to expand MAX_INSN_SIZE when we developed the booster.
The reasons are:
 - it is supplemental feature(just accelerating kprobes), if we have no space,
   we can disable it.
 - 5 bytes are big enough compared with 15(=MAX_INSN_SIZE)
 - the lengths of most of instructions are less than 10 bytes.

Additionally, MAX_INSN_SIZE is used in kernel/kprobes.c to allocate an
instruction buffer which will be assigned to p-ainsn.insn. Since the
instruction buffer size is MAX_INSN_SIZE, you can not copy instructions
more than MAX_INSN_SIZE.

BTW, in my patch, I unified MAX_INSN_SIZE to bigger one(16).
I think it is enough for us.

Thanks,

Best Regards,

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: [EMAIL PROTECTED], [EMAIL PROTECTED]

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/4] This patch adds kretprobe-booster to X86_64

2007-12-17 Thread Harvey Harrison

- Rewrite register saving/restoring code

Based on patch from Masami Hiramatsu [EMAIL PROTECTED]

Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
 arch/x86/kernel/kprobes.c |  104 +
 1 files changed, 58 insertions(+), 46 deletions(-)

diff --git a/arch/x86/kernel/kprobes.c b/arch/x86/kernel/kprobes.c
index 47bae2c..37a34a8 100644
--- a/arch/x86/kernel/kprobes.c
+++ b/arch/x86/kernel/kprobes.c
@@ -565,9 +565,8 @@ no_kprobe:
 }
 
 /*
- * For function-return probes, init_kprobes() establishes a probepoint
- * here. When a retprobed function returns, this probe is hit and
- * trampoline_probe_handler() runs, calling the kretprobe's handler.
+ * When a retprobed function returns,this code saves registers and
+ * calls trampoline_handler() runs, which calls the kretprobe's handler.
  */
 void __kprobes kretprobe_trampoline_holder(void)
 {
@@ -608,19 +607,59 @@ void __kprobes kretprobe_trampoline_holder(void)
 #else
asm volatile (  .global kretprobe_trampoline\n
kretprobe_trampoline: \n
-   nop\n);
+   /* We don't bother saving the ss register */
+  pushq %rsp\n
+  pushfq\n
+   /*
+* Skip cs, ip, orig_ax.
+* trampoline_handler() will plug in these values
+*/
+  subq $24, %rsp\n
+  pushq %rdi\n
+  pushq %rsi\n
+  pushq %rdx\n
+  pushq %rcx\n
+  pushq %rax\n
+  pushq %r8\n
+  pushq %r9\n
+  pushq %r10\n
+  pushq %r11\n
+  pushq %rbx\n
+  pushq %rbp\n
+  pushq %r12\n
+  pushq %r13\n
+  pushq %r14\n
+  pushq %r15\n
+  movq %rsp, %rdi\n
+  call trampoline_handler\n
+   /* Replace saved sp with true return address. */
+  movq %rax, 152(%rsp)\n
+  popq %r15\n
+  popq %r14\n
+  popq %r13\n
+  popq %r12\n
+  popq %rbp\n
+  popq %rbx\n
+  popq %r11\n
+  popq %r10\n
+  popq %r9\n
+  popq %r8\n
+  popq %rax\n
+  popq %rcx\n
+  popq %rdx\n
+  popq %rsi\n
+  popq %rdi\n
+   /* Skip orig_ax, ip, cs */
+  addq $24, %rsp\n
+  popfq\n
+  ret\n);
 #endif
 }
 
 /*
- * X86_32 Called from kretprobe_trampoline
- * X86_64 Called when we hit the probe point at kretprobe_trampoline
+ * Called from kretprobe_trampoline
  */
-#ifdef CONFIG_X86_32
-int __kprobes trampoline_probe_handler(struct kprobe *p, struct pt_regs *regs)
-#else
 void *__kprobes trampoline_handler(struct pt_regs *regs)
-#endif
 {
struct kretprobe_instance *ri = NULL;
struct hlist_head *head, empty_rp;
@@ -636,6 +675,11 @@ void *__kprobes trampoline_handler(struct pt_regs *regs)
regs-cs = __KERNEL_CS | get_kernel_rpl();
regs-ip = trampoline_address;
regs-orig_ax = 0x;
+#else
+   /* fixup rt regs */
+   regs-cs = __KERNEL_CS;
+   regs-ip = trampoline_address;
+   regs-orig_ax = 0x;
 #endif
/*
 * It is possible to have multiple instances associated with a given
@@ -654,17 +698,14 @@ void *__kprobes trampoline_handler(struct pt_regs *regs)
if (ri-task != current)
/* another task is sharing our hash bucket */
continue;
-#ifdef CONFIG_X86_32
+
if (ri-rp  ri-rp-handler) {
__get_cpu_var(current_kprobe) = ri-rp-kp;
get_kprobe_ctlblk()-kprobe_status = KPROBE_HIT_ACTIVE;
ri-rp-handler(ri, regs);
__get_cpu_var(current_kprobe) = NULL;
}
-#else
-   if (ri-rp  ri-rp-handler)
-   ri-rp-handler(ri, regs);
-#endif
+
orig_ret_address = (unsigned long)ri-ret_addr;
recycle_rp_inst(ri, empty_rp);
 
@@ -678,28 +719,14 @@ void *__kprobes trampoline_handler(struct pt_regs *regs)
}
 
kretprobe_assert(ri,

[PATCH 4/4] This patch adds kretprobe-booster to X86_64

2007-12-17 Thread Harvey Harrison

- Rewrite register saving/restoring code

Based on patch from Masami Hiramatsu [EMAIL PROTECTED]

Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
Sorry Ingo, I based my other 4/4 off the patch that had the one incorrect
ifdef around trampoline_probe_handler.  This is based on your fixed one.

Masami, I think you want to check your register restoration code in
trampoline_probe_handler vs X86_32, it's obvious in this patch in the
section:

X86_32:
regs-cs = __KERNEL_CS | get_kernel_rpl();

yours:
regs-cs = __KERNEL_CS;

 arch/x86/kernel/kprobes.c |  104 +
 1 files changed, 58 insertions(+), 46 deletions(-)

diff --git a/arch/x86/kernel/kprobes.c b/arch/x86/kernel/kprobes.c
index 47bae2c..37a34a8 100644
--- a/arch/x86/kernel/kprobes.c
+++ b/arch/x86/kernel/kprobes.c
@@ -565,9 +565,8 @@ no_kprobe:
 }
 
 /*
- * For function-return probes, init_kprobes() establishes a probepoint
- * here. When a retprobed function returns, this probe is hit and
- * trampoline_probe_handler() runs, calling the kretprobe's handler.
+ * When a retprobed function returns,this code saves registers and
+ * calls trampoline_handler() runs, which calls the kretprobe's handler.
  */
 void __kprobes kretprobe_trampoline_holder(void)
 {
@@ -608,19 +607,59 @@ void __kprobes kretprobe_trampoline_holder(void)
 #else
asm volatile (  .global kretprobe_trampoline\n
kretprobe_trampoline: \n
-   nop\n);
+   /* We don't bother saving the ss register */
+  pushq %rsp\n
+  pushfq\n
+   /*
+* Skip cs, ip, orig_ax.
+* trampoline_handler() will plug in these values
+*/
+  subq $24, %rsp\n
+  pushq %rdi\n
+  pushq %rsi\n
+  pushq %rdx\n
+  pushq %rcx\n
+  pushq %rax\n
+  pushq %r8\n
+  pushq %r9\n
+  pushq %r10\n
+  pushq %r11\n
+  pushq %rbx\n
+  pushq %rbp\n
+  pushq %r12\n
+  pushq %r13\n
+  pushq %r14\n
+  pushq %r15\n
+  movq %rsp, %rdi\n
+  call trampoline_handler\n
+   /* Replace saved sp with true return address. */
+  movq %rax, 152(%rsp)\n
+  popq %r15\n
+  popq %r14\n
+  popq %r13\n
+  popq %r12\n
+  popq %rbp\n
+  popq %rbx\n
+  popq %r11\n
+  popq %r10\n
+  popq %r9\n
+  popq %r8\n
+  popq %rax\n
+  popq %rcx\n
+  popq %rdx\n
+  popq %rsi\n
+  popq %rdi\n
+   /* Skip orig_ax, ip, cs */
+  addq $24, %rsp\n
+  popfq\n
+  ret\n);
 #endif
 }
 
 /*
- * X86_32 Called from kretprobe_trampoline
- * X86_64 Called when we hit the probe point at kretprobe_trampoline
+ * Called from kretprobe_trampoline
  */
-#ifdef CONFIG_X86_64
-int __kprobes trampoline_probe_handler(struct kprobe *p, struct pt_regs *regs)
-#else
 void *__kprobes trampoline_handler(struct pt_regs *regs)
-#endif
 {
struct kretprobe_instance *ri = NULL;
struct hlist_head *head, empty_rp;
@@ -636,6 +675,11 @@ void *__kprobes trampoline_handler(struct pt_regs *regs)
regs-cs = __KERNEL_CS | get_kernel_rpl();
regs-ip = trampoline_address;
regs-orig_ax = 0x;
+#else
+   /* fixup rt regs */
+   regs-cs = __KERNEL_CS;
+   regs-ip = trampoline_address;
+   regs-orig_ax = 0x;
 #endif
/*
 * It is possible to have multiple instances associated with a given
@@ -654,17 +698,14 @@ void *__kprobes trampoline_handler(struct pt_regs *regs)
if (ri-task != current)
/* another task is sharing our hash bucket */
continue;
-#ifdef CONFIG_X86_32
+
if (ri-rp  ri-rp-handler) {
__get_cpu_var(current_kprobe) = ri-rp-kp;
get_kprobe_ctlblk()-kprobe_status = KPROBE_HIT_ACTIVE;
ri-rp-handler(ri, regs);
__get_cpu_var(current_kprobe)

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

2007-12-17 Thread Alan Cox

 responds to reads differently than unused ports.  In particular, an 
 inb takes 1/2 the elapsed time compared to a read to known unused port 
 0xed - 792 tsc ticks for port 80 compared to about 1450 tsc ticks for 
 port 0xed and other unused ports (tsc at 800 MHz).

Well at least we know where the port is now - thats too fast for an LPC
bus device, so it must be an SMI trap.

Only easy way to find out is to use the debugging event counters and see
how many instruction cycles are issued as part of the 0x80 port. If its
suprisingly high then you've got a firmware bug and can go spank HP.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] x86: provide a DMI based port 0x80 I/O delay override.

2007-12-17 Thread Rene Herman


On 17-12-07 21:57, H. Peter Anvin wrote:


Rene Herman wrote:

On 17-12-07 17:12, Alan Cox wrote:


I don't think we should be offering udelay based delays at this point.
There are a lot of drivers to fix first. This is just one trivial 
example


I agree. This thread's too full of people calling this outb method a 
dumb hack. It's a well-known legacy PC thing and while in practice the 
udelay might be a functional replacement for a majority of cases (save 
the races you are finding) a delay proportional to the bus speed makes 
great sense certainly when talking to hardware that itself runs 
proportinal to the bus speed for example.


So, really, how about just sticking in this minimal version for now? 
Only switches the port to 0xed based on DMI and is all that is needed 
to fix the actual problem. This should be minimal and no-risk enough 
that it could also go to .24 if people want it to. It'll fix a few HP 
laptops (I'll try and get/verify the dv6000z DMI strings as well).




I think retaining the command-line option available is a good thing, 
though.  If nothing else, it is something very quick we can ask other 
people to try if they seem to have similar problems.


Well, yes, I guess that does make sense. It's back again. Named the choices 
standard and alternate again as I feel 0x80 and 0xed suggest they're 
free values a bit too much but if anyone feels strongly about it, so be it.


Other than that, this alternate-port patch is a low-impact patch not 
affecting hardware not on the blacklist, which makes it appropriate for 
2.6.24 IMO.


Signed-off-by: Rene Herman [EMAIL PROTECTED]
commit c83008ff40e95f89407807cb122127c5444b3bc4
Author: Rene Herman [EMAIL PROTECTED]
Date:   Mon Dec 17 21:23:55 2007 +0100

x86: provide a DMI based port 0x80 I/O delay override.

Certain (HP) laptops experience trouble from our port 0x80 I/O delay
writes. This patch provides for a DMI based switch to the alternate
diagnostic port 0xed (as used by some BIOSes as well) for these.

David P. Reed confirmed that port 0xed works for him and provides a
proper delay. The symptoms of _not_ working are a hanging machine,
with hwclock use being a direct trigger.

Earlier versions of this attempted to simply use udelay(2), with the
2 being a value tested to be a nicely conservative upper-bound with
help from many on the linux-kernel mailinglist, but that approach has
two problems.

First, pre-loops_per_jiffy calibration (which is post PIT init while
some implementations of the PIT are actually one of the historically
problematic devices that need the delay) udelay() isn't particularly
well-defined. We could initialise loops_per_jiffy conservatively (and
based on CPU family so as to not unduly delay old machines) which
would sort of work, but still leaves:

Second, delaying isn't the only effect that a write to port 0x80 has.
It's also a PCI posting barrier which some devices may be explicitly
or implicitly relying on. Alan Cox did a survey and found evidence
that additionally various drivers are racy on SMP without the bus
locking outb.

Switching to an inb() makes the timing too unpredictable and as such,
this DMI based switch should be the safest approach for now. Any more
invasive changes should get more rigid testing first. It's moreover
only very few machines with the problem and a DMI based hack seems
to fit that situation.

An early boot parameter to make the choice manually (and override any
possible DMI based decision) is also provided:

io_delay=standard|alternate

This does not change the io_delay() in the boot code which is using
the same port 0x80 I/O delay but those do not appear to be a problem
as tested by David P. Reed. He moreover reported that booting with
acpi=off also fixed things and seeing as how ACPI isn't touched
until after this DMI based I/O port switch leaving the ones in the
boot code be is safe.

The DMI strings from David's HP Pavilion dv9000z are in there already
and we need to get/verify the DMI info from other machines with the
problem, notably the HP Pavilion dv6000z.

This patch is partly based on earlier patches from Pavel Machek and
David P. Reed.

Signed-off-by: Rene Herman [EMAIL PROTECTED]

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 33121d6..ff66cf4 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -785,6 +785,13 @@ and is between 256 and 4096 characters. It is defined in 
the file
for translation below 32 bit and if not available
then look in the higher range.
 
+   io_delay=   [X86-32,X86-64] I/O delay port
+   standard
+   Use the 0x80 standard I/O delay port (default)
+

Re: FInal kprobes rollup patches

2007-12-17 Thread Harvey Harrison

On Mon, 2007-12-17 at 16:28 -0500, Masami Hiramatsu wrote:
 Hi Harvey,
 If you mention about a relative jump which is inserted by
 resume_execution(), I think you might misunderstand that relative jump.
 
 The size of that relative jump, which will be embedded by kprobe-booster, is
 5-bytes(not 1 byte). So it needs 5 bytes space.
 And we decided not to expand MAX_INSN_SIZE when we developed the booster.
 The reasons are:
  - it is supplemental feature(just accelerating kprobes), if we have no space,
we can disable it.
  - 5 bytes are big enough compared with 15(=MAX_INSN_SIZE)
  - the lengths of most of instructions are less than 10 bytes.
 
 Additionally, MAX_INSN_SIZE is used in kernel/kprobes.c to allocate an
 instruction buffer which will be assigned to p-ainsn.insn. Since the
 instruction buffer size is MAX_INSN_SIZE, you can not copy instructions
 more than MAX_INSN_SIZE.
 
 BTW, in my patch, I unified MAX_INSN_SIZE to bigger one(16).
 I think it is enough for us.
 

I went with 15 in mine, I thought it made the code a little more
readable, but I will defer if you think 16 is better.  If you want me
to send the whole series to you, let me know.

I just sent out a series of 4 patches equivalent to your patches 1-4/6
but based on my already unified kprobes.c/h, You may want to check your
handling of restored registers in trampoline_probe_handler which I found
when rebasing yours on top of my cleanups.  Not sure if this is
important, but it was a difference I found.

X86_32:
regs-cs = __KERNEL_CS | get_kernel_rpl();

yours:
regs-cs = __KERNEL_CS;

Harvey

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Top kernel oopses/warnings this week

2007-12-17 Thread Arjan van de Ven

On Mon, 17 Dec 2007 18:23:31 +0100
Ingo Molnar [EMAIL PROTECTED] wrote:

 
 * Arjan van de Ven [EMAIL PROTECTED] wrote:
 
  The http://www.kerneloops.org website collects kernel oops and
  warning reports from various mailing lists and bugzillas; below is
  a top 10 list of the oopses collected in the last 7 days. (Reports
  prior to 2.6.23 have been omitted in collecting the top 10)
 
 cool stuff! I cannot over-emphasise how useful this will be.
 
 Let us know if you need any additional WARN_ON()s or other dmesg 
 annotations to make parsing easier / more intelligent. At least as
 far as arch/x86 and the scheduler is related it's going to be applied
 to the fast-track queue ;-)


the following patch would help a lot; it ads a very nice parsable end-marker
to oopses, as well as printing the boot UUID as part of the oops, which 
makes it easier to de-dupe oopses. The UUID is just a random number and not
privacy-tracable to any system.

--

Subject: [patch] terminate the oops printing with a defined string/uuid
From: Arjan van de Ven [EMAIL PROTECTED]

Right now, it's hard for automated tools to determine when an oops has
ended; there's no clear marker for this. In addition, there's no good
way to find out if an oops is unique. Sometimes it's the same oops
just reported multiple times, while other times it's a different
instance of the crash with the same signature. Printing the boot UUID
as part of the end string resolves this ambiguity.

Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]
CC: Ted Ts'o [EMAIL PROTECTED]

---
 drivers/char/random.c  |   35 ++-
 include/linux/random.h |1 +
 kernel/panic.c |2 ++
 3 files changed, 37 insertions(+), 1 deletion(-)

Index: linux-2.6.24-rc5/drivers/char/random.c
===
--- linux-2.6.24-rc5.orig/drivers/char/random.c
+++ linux-2.6.24-rc5/drivers/char/random.c
@@ -1176,8 +1176,41 @@ static int max_read_thresh = INPUT_POOL_
 static int max_write_thresh = INPUT_POOL_WORDS * 32;
 static char sysctl_bootid[16];
 
+/**
+ * get_boot_uuid   - return a string pointer to a system wide boot UUID
+ *
+ * Returns a pointer to the boot UUID. This UUID is unique per system
+ * boot but persistent for one boot session.
+ *
+ * The memory returned via the return pointer is static allocated and
+ * owned by the random.c driver; this should not be kfree()'d.
+ *
+ * Locking: none
+ */
+ */
+char *get_boot_uuid(void)
+{
+   static char target[80];
+   unsigned char *uuid;
+
+   if (sysctl_bootid[8] == 0)
+   generate_random_uuid(sysctl_bootid);
+   /* sysctl_bootid is signed, to print we need unsigned .. */
+   uuid = sysctl_bootid;
+
+   if (target[0] == 0) {
+   sprintf(target, %02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-
+   %02x%02x%02x%02x%02x%02x,
+   uuid[0],  uuid[1],  uuid[2],  uuid[3],  uuid[4],
+   uuid[5],  uuid[6],  uuid[7],  uuid[8],  uuid[9],
+   uuid[10], uuid[11], uuid[12], uuid[13], uuid[14],
+   uuid[15]);
+   }
+   return target;
+}
+
 /*
- * These functions is used to return both the bootid UUID, and random
+ * These functions are used to return both the bootid UUID, and random
  * UUID.  The difference is in whether table-data is NULL; if it is,
  * then a new UUID is generated and returned to the user.
  *
Index: linux-2.6.24-rc5/include/linux/random.h
===
--- linux-2.6.24-rc5.orig/include/linux/random.h
+++ linux-2.6.24-rc5/include/linux/random.h
@@ -71,6 +71,7 @@ unsigned long randomize_range(unsigned l
 
 u32 random32(void);
 void srandom32(u32 seed);
+char *get_boot_uuid(void);
 
 #endif /* __KERNEL___ */
 
Index: linux-2.6.24-rc5/kernel/panic.c
===
--- linux-2.6.24-rc5.orig/kernel/panic.c
+++ linux-2.6.24-rc5/kernel/panic.c
@@ -19,6 +19,7 @@
 #include linux/nmi.h
 #include linux/kexec.h
 #include linux/debug_locks.h
+#include linux/random.h
 
 int panic_on_oops;
 int tainted;
@@ -272,6 +273,7 @@ void oops_enter(void)
 void oops_exit(void)
 {
do_oops_enter_exit();
+   printk(---[ end of trace %s ]---\n, get_boot_uuid());
 }
 
 #ifdef CONFIG_CC_STACKPROTECTOR
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] lack of /proc/net/ax25 with 2.6.24-rc5

2007-12-17 Thread Rafael J. Wysocki

On Sunday, 16 of December 2007, Bernard Pidoux wrote:
 With 2.6.24-rc5 there is no /proc/net/ax25

FYI, I've created a Bugzilla entry for this issue at:
http://bugzilla.kernel.org/show_bug.cgi?id=9589

Please add your address to the CC list in there.

Thanks,
Rafael


 Here is an extract from dmesg after boot :
 
 ===
 sysctl table check failed: /net/ax25/ax0/ax25_default_mode .3.9.1.2 
 Unknown sysctl binary path
 Pid: 2936, comm: kissattach Not tainted 2.6.24-rc5 #1
   [c012ca6a] set_fail+0x3b/0x43
   [c012ce7a] sysctl_check_table+0x408/0x456
   [c012ce8e] sysctl_check_table+0x41c/0x456
   [c012ce8e] sysctl_check_table+0x41c/0x456
   [c02ac64a] _spin_unlock+0x14/0x1c
   [c012ce8e] sysctl_check_table+0x41c/0x456
   [c011e681] sysctl_set_parent+0x19/0x2a
   [c011f55c] register_sysctl_table+0x45/0x85
   [d8be9d26] ax25_register_sysctl+0x112/0x11c [ax25]
   [d8be6c76] ax25_device_event+0x2e/0x90 [ax25]
   [c012c560] notifier_call_chain+0x2a/0x47
   [c012c59f] raw_notifier_call_chain+0x17/0x1a
   [c0259290] dev_open+0x6f/0x75
   [c0257ee7] dev_change_flags+0x9c/0x148
   [c0256ab3] __dev_get_by_name+0x68/0x73
   [c0292307] devinet_ioctl+0x22e/0x53b
   [c0259074] dev_ioctl+0x472/0x5ba
   [c024d4ba] sock_ioctl+0x1aa/0x1cf
   [c024d310] sock_ioctl+0x0/0x1cf
   [c016bc19] do_ioctl+0x19/0x4c
   [c016be40] vfs_ioctl+0x1f4/0x20b
   [c0103d01] sysenter_past_esp+0x9a/0xa9
   [c016be9c] sys_ioctl+0x45/0x5d
   [c0103cc6] sysenter_past_esp+0x5f/0xa9
   ===
 sysctl table check failed: /net/ax25/ax0/backoff_type .3.9.1.3 Unknown 
 sysctl binary path
 (...) truncated
   ===
 sysctl table check failed: /net/ax25/ax0/connect_mode .3.9.1.4 Unknown 
 sysctl binary path
 (...)
   ===
 sysctl table check failed: /net/ax25/ax0/standard_window_size .3.9.1.5 
 Unknown sysctl binary path
   ===
 (...)
 
 and so on ...
 
 
 
 Bernard Pidoux
 [EMAIL PROTECTED]
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
 
 



-- 
Premature optimization is the root of all evil. - Donald Knuth
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] PCI: fix for quirk_e100_interrupt()

2007-12-17 Thread Ivan Kokshaysky

Check that the e100 is in the D0 power state. If it's not, it won't
respond to MMIO accesses and we end up with master-abort machine
checks on some platforms.

Signed-off-by: Ivan Kokshaysky [EMAIL PROTECTED]
---
 drivers/pci/quirks.c |   14 +-
 1 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 26cc4dc..c8b2b9d 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -1406,9 +1406,10 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NETMOS, 
PCI_ANY_ID, quirk_netmos);
 
 static void __devinit quirk_e100_interrupt(struct pci_dev *dev)
 {
-   u16 command;
+   u16 command, pmcsr;
u8 __iomem *csr;
u8 cmd_hi;
+   int pm;
 
switch (dev-device) {
/* PCI IDs taken from drivers/net/e100.c */
@@ -1442,6 +1443,17 @@ static void __devinit quirk_e100_interrupt(struct 
pci_dev *dev)
if (!(command  PCI_COMMAND_MEMORY) || !pci_resource_start(dev, 0))
return;
 
+   /*
+* Check that the device is in the D0 power state. If it's not,
+* there is no point to look any further.
+*/
+   pm = pci_find_capability(dev, PCI_CAP_ID_PM);
+   if (pm) {
+   pci_read_config_word(dev, pm + PCI_PM_CTRL, pmcsr);
+   if ((pmcsr  PCI_PM_CTRL_STATE_MASK) != PCI_D0)
+   return;
+   }
+
/* Convert from PCI bus to resource space.  */
csr = ioremap(pci_resource_start(dev, 0), 8);
if (!csr) {
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

2007-12-17 Thread H. Peter Anvin


Rene Herman wrote:


Well, yes, I guess that does make sense. It's back again. Named the 
choices standard and alternate again as I feel 0x80 and 0xed 
suggest they're free values a bit too much but if anyone feels strongly 
about it, so be it.




They ARE -- or really, should be, free values (0xeb and 0xf0 are other 
reasonable values, for example.)


-hpa
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

2007-12-17 Thread Ingo Molnar


* Rene Herman [EMAIL PROTECTED] wrote:

 On 17-12-07 17:12, Alan Cox wrote:

 I don't think we should be offering udelay based delays at this point.
 There are a lot of drivers to fix first. This is just one trivial example

 I agree. This thread's too full of people calling this outb method a 
 dumb hack. It's a well-known legacy PC thing and while in practice the 
 udelay might be a functional replacement for a majority of cases (save 
 the races you are finding) a delay proportional to the bus speed makes 
 great sense certainly when talking to hardware that itself runs 
 proportinal to the bus speed for example.

 So, really, how about just sticking in this minimal version for now? 
 Only switches the port to 0xed based on DMI and is all that is needed 
 to fix the actual problem. This should be minimal and no-risk enough 
 that it could also go to .24 if people want it to. It'll fix a few HP 
 laptops (I'll try and get/verify the dv6000z DMI strings as well).

 Ingo?

 Signed-off-by: Rene Herman [EMAIL PROTECTED]

hm, i see this as a step backwards from the pretty flexible patch that 
David already tested. (and which also passed a few hundred bootup tests 
on my x86 test-grid)

Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.24-rc5: tape drive not responding

2007-12-17 Thread Andrew Morton

On Mon, 17 Dec 2007 16:02:02 -0500
John Stoffel [EMAIL PROTECTED] wrote:

 
 Just to confirm, the propsed patch to st.c fixes the issue with
 2.6.24-rc5 as well at 2.6.24-rc5-mm1 with access to my DLT tape
 drives.

err, what patch to st.c?

So it seems that 2.6.24 (and presumably 2.6.23?) need

1: Alan's initio: fix conflict when loading driver (currently stocuk
   in git-scsi-misc)

2: Boaz's initio: initio_build_scb() fix (my name for it)

3: The mystery st.c fix.

yes?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

2007-12-17 Thread Ingo Molnar


* H. Peter Anvin [EMAIL PROTECTED] wrote:

 Rene Herman wrote:

 Well, yes, I guess that does make sense. It's back again. Named the 
 choices standard and alternate again as I feel 0x80 and 0xed 
 suggest they're free values a bit too much but if anyone feels 
 strongly about it, so be it.

 They ARE -- or really, should be, free values (0xeb and 0xf0 are other 
 reasonable values, for example.)

yeah. We've got the variant below for now, tested by David. We can still 
change things later on if the need arises.

Ingo

--
Subject: x86: provide a DMI based port 0x80 I/O delay override.
From: Rene Herman [EMAIL PROTECTED]

x86: provide a DMI based port 0x80 I/O delay override.

Certain (HP) laptops experience trouble from our port 0x80 I/O delay
writes. This patch provides for a DMI based switch to the alternate
diagnostic port 0xed (as used by some BIOSes as well) for these.

David P. Reed confirmed that port 0xed works for him and provides a
proper delay. The symptoms of _not_ working are a hanging machine,
with hwclock use being a direct trigger.

Earlier versions of this attempted to simply use udelay(2), with the
2 being a value tested to be a nicely conservative upper-bound with
help from many on the linux-kernel mailinglist but that approach has
two problems.

First, pre-loops_per_jiffy calibration (which is post PIT init while
some implementations of the PIT are actually one of the historically
problematic devices that need the delay) udelay() isn't particularly
well-defined. We could initialise loops_per_jiffy conservatively (and
based on CPU family so as to not unduly delay old machines) which
would sort of work, but...

Second, delaying isn't the only effect that a write to port 0x80 has.
It's also a PCI posting barrier which some devices may be explicitly
or implicitly relying on. Alan Cox did a survey and found evidence
that additionally some drivers may be racy on SMP without the bus
locking outb.

Switching to an inb() makes the timing too unpredictable and as such,
this DMI based switch should be the safest approach for now. Any more
invasive changes should get more rigid testing first. It's moreover
only very few machines with the problem and a DMI based hack seems
to fit that situation.

This also introduces a command-line parameter io_delay to override
the DMI based choice again:

io_delay=0x80|0xed|udelay|none

where 0x80 means using the standard port 0x80 and 0xed means the
alternate port 0xed.

All these methods can also be selected via the kernel .config,
and can be runtime tuned via /proc/sys/kernel/io_delay_type (for
debugging purposes).

The DMI strings from David's HP Pavilion dv9000z are in there already
and we need to get/verify the DMI info from other machines with the
problem, notably the HP Pavilion dv6000z.

This patch is partly based on earlier patches from Pavel Machek and
David P. Reed.

[ [EMAIL PROTECTED]:
  - add the io_delay=none method
  - make each method selectable from the kernel config
  - eliminate the indirect function calls
  - add the /proc/sys/kernel/io_delay_type sysctl
  - change 'standard' and 'alternate' to 0x80 and 0xed
  - make the io delay config not depend on CONFIG_DEBUG_KERNEL ]

Signed-off-by: Rene Herman [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
Tested-by: David P. Reed [EMAIL PROTECTED]
---
 Documentation/kernel-parameters.txt |   10 +++
 arch/x86/Kconfig.debug  |   74 +++
 arch/x86/boot/compressed/misc_32.c  |8 +-
 arch/x86/boot/compressed/misc_64.c  |8 +-
 arch/x86/kernel/Makefile_32 |2 
 arch/x86/kernel/Makefile_64 |2 
 arch/x86/kernel/io_delay.c  |   98 
 arch/x86/kernel/setup_32.c  |2 
 arch/x86/kernel/setup_64.c  |2 
 include/asm-x86/io_32.h |8 +-
 include/asm-x86/io_64.h |   29 ++
 kernel/sysctl.c |9 +++
 12 files changed, 227 insertions(+), 25 deletions(-)

Index: linux-x86.q/Documentation/kernel-parameters.txt
===
--- linux-x86.q.orig/Documentation/kernel-parameters.txt
+++ linux-x86.q/Documentation/kernel-parameters.txt
@@ -785,6 +785,16 @@ and is between 256 and 4096 characters. 
for translation below 32 bit and if not available
then look in the higher range.
 
+   io_delay=   [X86-32,X86-64] I/O delay method
+   0x80
+   Standard port 0x80 based delay
+   0xed
+   Alternate port 0xed based delay (needed on some systems)
+   udelay
+   Simple two microseconds delay
+   none
+   No delay
+
io7=[HW] IO7 for Marvel based alpha systems
See comment before

Re: 2.6.24-rc5: tape drive not responding

2007-12-17 Thread Jean-Louis Dupond


http://marc.info/?l=linux-scsim=119770154127770w=2

There is the patch for st.c

Andrew Morton schreef:

On Mon, 17 Dec 2007 16:02:02 -0500
John Stoffel [EMAIL PROTECTED] wrote:


Just to confirm, the propsed patch to st.c fixes the issue with
2.6.24-rc5 as well at 2.6.24-rc5-mm1 with access to my DLT tape
drives.


err, what patch to st.c?

So it seems that 2.6.24 (and presumably 2.6.23?) need

1: Alan's initio: fix conflict when loading driver (currently stocuk
   in git-scsi-misc)

2: Boaz's initio: initio_build_scb() fix (my name for it)

3: The mystery st.c fix.

yes?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

2007-12-17 Thread Rene Herman


On 17-12-07 22:41, Ingo Molnar wrote:

* Rene Herman [EMAIL PROTECTED] wrote:


On 17-12-07 17:12, Alan Cox wrote:


I don't think we should be offering udelay based delays at this point.
There are a lot of drivers to fix first. This is just one trivial example
I agree. This thread's too full of people calling this outb method a 
dumb hack. It's a well-known legacy PC thing and while in practice the 
udelay might be a functional replacement for a majority of cases (save 
the races you are finding) a delay proportional to the bus speed makes 
great sense certainly when talking to hardware that itself runs 
proportinal to the bus speed for example.


So, really, how about just sticking in this minimal version for now? 
Only switches the port to 0xed based on DMI and is all that is needed 
to fix the actual problem. This should be minimal and no-risk enough 
that it could also go to .24 if people want it to. It'll fix a few HP 
laptops (I'll try and get/verify the dv6000z DMI strings as well).


Ingo?

Signed-off-by: Rene Herman [EMAIL PROTECTED]


hm, i see this as a step backwards from the pretty flexible patch that 
David already tested. (and which also passed a few hundred bootup tests 
on my x86 test-grid)


Please see Alan's comment that udelay (and none) shouldn't yet be provided 
as a choice. It opens race windows in drivers even when it works in practice 
on most setups. The version with udelay and none is not minimal, not low 
risk and certainly not .24 material.


David tested this part of the patch just as well.

Attached again (with the boot param) since I see I left in an extraneous 
'Use the in the kernel-parameters.txt file.


Rene.
commit c12c7a47b9af87e8d867d5aa0ca5c6bcdd2463da
Author: Rene Herman [EMAIL PROTECTED]
Date:   Mon Dec 17 21:23:55 2007 +0100

x86: provide a DMI based port 0x80 I/O delay override.

Certain (HP) laptops experience trouble from our port 0x80 I/O delay
writes. This patch provides for a DMI based switch to the alternate
diagnostic port 0xed (as used by some BIOSes as well) for these.

David P. Reed confirmed that port 0xed works for him and provides a
proper delay. The symptoms of _not_ working are a hanging machine,
with hwclock use being a direct trigger.

Earlier versions of this attempted to simply use udelay(2), with the
2 being a value tested to be a nicely conservative upper-bound with
help from many on the linux-kernel mailinglist, but that approach has
two problems.

First, pre-loops_per_jiffy calibration (which is post PIT init while
some implementations of the PIT are actually one of the historically
problematic devices that need the delay) udelay() isn't particularly
well-defined. We could initialise loops_per_jiffy conservatively (and
based on CPU family so as to not unduly delay old machines) which
would sort of work, but still leaves:

Second, delaying isn't the only effect that a write to port 0x80 has.
It's also a PCI posting barrier which some devices may be explicitly
or implicitly relying on. Alan Cox did a survey and found evidence
that additionally various drivers are racy on SMP without the bus
locking outb.

Switching to an inb() makes the timing too unpredictable and as such,
this DMI based switch should be the safest approach for now. Any more
invasive changes should get more rigid testing first. It's moreover
only very few machines with the problem and a DMI based hack seems
to fit that situation.

An early boot parameter to make the choice manually (and override any
possible DMI based decision) is also provided:

io_delay=standard|alternate

This does not change the io_delay() in the boot code which is using
the same port 0x80 I/O delay but those do not appear to be a problem
as tested by David P. Reed. He moreover reported that booting with
acpi=off also fixed things and seeing as how ACPI isn't touched
until after this DMI based I/O port switch leaving the ones in the
boot code be is safe.

The DMI strings from David's HP Pavilion dv9000z are in there already
and we need to get/verify the DMI info from other machines with the
problem, notably the HP Pavilion dv6000z.

This patch is partly based on earlier patches from Pavel Machek and
David P. Reed.

Signed-off-by: Rene Herman [EMAIL PROTECTED]

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 33121d6..6948e25 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -785,6 +785,12 @@ and is between 256 and 4096 characters. It is defined in 
the file
for translation below 32 bit and if not available
then look in the higher range.
 
+   io_delay=   [X86-32,X86-64] I/O delay port
+   standard
+   Use the

Re: 2.6.24-rc5: tape drive not responding

2007-12-17 Thread James Bottomley


On Mon, 2007-12-17 at 13:43 -0800, Andrew Morton wrote:
 On Mon, 17 Dec 2007 16:02:02 -0500
 John Stoffel [EMAIL PROTECTED] wrote:
 
  
  Just to confirm, the propsed patch to st.c fixes the issue with
  2.6.24-rc5 as well at 2.6.24-rc5-mm1 with access to my DLT tape
  drives.
 
 err, what patch to st.c?

That's this one:

http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commit;h=acdd0b1c371b2fbb4b6110a51ba69cb0af9e6f45

 So it seems that 2.6.24 (and presumably 2.6.23?) need

Not 2.6.23 .. the scatterlist changes causing the st problems are local
to 2.6.24.

 1: Alan's initio: fix conflict when loading driver (currently stocuk
in git-scsi-misc)

Yes, I'm moving this into scsi-rc-fixes

 2: Boaz's initio: initio_build_scb() fix (my name for it)

And applying this ... although I'd still appreciate confirmation from
someone that the initio driver works after this.

 3: The mystery st.c fix.
 
 yes?

James


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

2007-12-17 Thread Rene Herman


On 17-12-07 22:40, H. Peter Anvin wrote:


Rene Herman wrote:


Well, yes, I guess that does make sense. It's back again. Named the 
choices standard and alternate again as I feel 0x80 and 0xed 
suggest they're free values a bit too much but if anyone feels 
strongly about it, so be it.




They ARE -- or really, should be, free values (0xeb and 0xf0 are other 
reasonable values, for example.)


I was afraid someone would say that. Making a random port available is fine 
for testing purposes but a failry dangerous thing to do generally. For a 
minimal version at -rc4 time, I believe sticking with 0x80 and 0xed ie best.


Lots of time during .25 to go wild...

Rene.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: FInal kprobes rollup patches

2007-12-17 Thread Masami Hiramatsu

Hi Harvey,

Harvey Harrison wrote:
 On Mon, 2007-12-17 at 16:28 -0500, Masami Hiramatsu wrote:
 Hi Harvey,
 If you mention about a relative jump which is inserted by
 resume_execution(), I think you might misunderstand that relative jump.

 The size of that relative jump, which will be embedded by kprobe-booster, is
 5-bytes(not 1 byte). So it needs 5 bytes space.
 And we decided not to expand MAX_INSN_SIZE when we developed the booster.
 The reasons are:
  - it is supplemental feature(just accelerating kprobes), if we have no 
 space,
we can disable it.
  - 5 bytes are big enough compared with 15(=MAX_INSN_SIZE)
  - the lengths of most of instructions are less than 10 bytes.

 Additionally, MAX_INSN_SIZE is used in kernel/kprobes.c to allocate an
 instruction buffer which will be assigned to p-ainsn.insn. Since the
 instruction buffer size is MAX_INSN_SIZE, you can not copy instructions
 more than MAX_INSN_SIZE.

 BTW, in my patch, I unified MAX_INSN_SIZE to bigger one(16).
 I think it is enough for us.

 
 I went with 15 in mine, I thought it made the code a little more
 readable, but I will defer if you think 16 is better.  If you want me
 to send the whole series to you, let me know.

Before porting, could you tell me what differences are important
to you? We can discuss about it.

 I just sent out a series of 4 patches equivalent to your patches 1-4/6
 but based on my already unified kprobes.c/h, You may want to check your
 handling of restored registers in trampoline_probe_handler which I found
 when rebasing yours on top of my cleanups.  Not sure if this is
 important, but it was a difference I found.
 
 X86_32:
 regs-cs = __KERNEL_CS | get_kernel_rpl();
 
 yours:
 regs-cs = __KERNEL_CS;

Because of kretprobe's compatibility, on x86-32 cs should be set rpl().
But get_kernel_rpl() does not exist on x86-64.

Thanks,

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: [EMAIL PROTECTED], [EMAIL PROTECTED]

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: slab quirks in DEBUG, ctor, and initialization

2007-12-17 Thread Pekka J Enberg

Hi John,

On Mon, 17 Dec 2007, John Reiser wrote:
 idr_pre_get calls kmem_cache_alloc, which constructs 'struct idr_layer'
 via the cachep-ctor() call from cache_alloc_debugcheck_after to
 idr_cache_ctor, and not via cache_init_objs.  So if DEBUG is off,
 then idr_cache_ctor does not get its chance to call memset,
 which could leave the struct idr_layer potentially undefined.

No, init_cache_objs() will call the constructor, if the cache has one when 
DEBUG is not set so the struct idr_layer can never be undefined. However, 
struct idr_layer can contain non-zero elements if someone does a 
kmem_cache_free() on an object that hasn't been zeroed. If that matters 
here, idr_pre_get should call kmem_cache_zalloc() and drop the 
constructor.

Pekka
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers/scsi/: Spelling fixes

2007-12-17 Thread Andrew Vasquez

On Mon, 17 Dec 2007, Joe Perches wrote:

 Signed-off-by: Joe Perches [EMAIL PROTECTED]
 ---
  drivers/scsi/NCR53C9x.h   |2 +-
  drivers/scsi/aic7xxx/aic79xx_inline.h |2 +-
  drivers/scsi/aic7xxx/aic79xx_osm.c|2 +-
  drivers/scsi/aic7xxx/aic79xx_pci.c|4 ++--
  drivers/scsi/aic7xxx/aic7xxx_inline.h |2 +-
  drivers/scsi/aic7xxx/aic7xxx_osm.c|2 +-
  drivers/scsi/ipr.c|2 +-
  drivers/scsi/ips.c|2 +-
  drivers/scsi/iscsi_tcp.c  |4 ++--
  drivers/scsi/lpfc/lpfc.h  |2 +-
  drivers/scsi/lpfc/lpfc_mbox.c |2 +-
  drivers/scsi/megaraid/megaraid_mbox.c |   10 +-
  drivers/scsi/psi240i.c|2 +-
  drivers/scsi/qla2xxx/qla_gs.c |2 +-

qla2xxx bits:

Acked-by: Andrew Vasquez [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

2007-12-17 Thread Ingo Molnar


* Rene Herman [EMAIL PROTECTED] wrote:

 Signed-off-by: Rene Herman [EMAIL PROTECTED]

 hm, i see this as a step backwards from the pretty flexible patch 
 that David already tested. (and which also passed a few hundred 
 bootup tests on my x86 test-grid)

 Please see Alan's comment that udelay (and none) shouldn't yet be 
 provided as a choice. It opens race windows in drivers even when it 
 works in practice on most setups. The version with udelay and none 
 is not minimal, not low risk and certainly not .24 material.

huh? By default we still use port 0x80. Any udelay is non-default and 
needs the user to explicitly switch to it. But it enables us to debug 
any suspected drivers by asking testers to: please try this driver with 
io_delay=udelay, does it still work fine?. So those extra options are 
quite sensible. If you have any real technical arguments against that 
then please let us know.

Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Top kernel oopses/warnings this week

2007-12-17 Thread Theodore Tso

On Mon, Dec 17, 2007 at 01:36:31PM -0800, Arjan van de Ven wrote:
 Subject: [patch] terminate the oops printing with a defined string/uuid
 From: Arjan van de Ven [EMAIL PROTECTED]

 Right now, it's hard for automated tools to determine when an oops has
 ended; there's no clear marker for this. In addition, there's no good
 way to find out if an oops is unique. Sometimes it's the same oops
 just reported multiple times, while other times it's a different
 instance of the crash with the same signature. Printing the boot UUID
 as part of the end string resolves this ambiguity.

 Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]
 CC: Ted Ts'o [EMAIL PROTECTED]

Looks good to me!

Signed-off-by: Theodore Ts'o [EMAIL PROTECTED]

- Ted
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

2007-12-17 Thread Rene Herman


On 17-12-07 22:56, Ingo Molnar wrote:


* Rene Herman [EMAIL PROTECTED] wrote:


Signed-off-by: Rene Herman [EMAIL PROTECTED]
hm, i see this as a step backwards from the pretty flexible patch 
that David already tested. (and which also passed a few hundred 
bootup tests on my x86 test-grid)
Please see Alan's comment that udelay (and none) shouldn't yet be 
provided as a choice. It opens race windows in drivers even when it 
works in practice on most setups. The version with udelay and none 
is not minimal, not low risk and certainly not .24 material.


huh? By default we still use port 0x80. Any udelay is non-default and 
needs the user to explicitly switch to it.  But it enables us to debug
any suspected drivers by asking testers to: please try this driver with 
io_delay=udelay, does it still work fine?. So those extra options are 
quite sensible. If you have any real technical arguments against that 
then please let us know.


Ingo, have lots of fun playing with yourself, but remove my sign off from 
anything with the udelay and none methods.


Rene.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

2007-12-17 Thread mvtodevnull

On Dec 17, 2007 5:35 AM,  [EMAIL PROTECTED] wrote:
 If this is a mac80211 related problem, then other systems connecting
 to the same ap and using mac80211 would also be affected? Like I said
 earlier, there are five machines connecting to this ap, and I just
 realized one of them has a ralink card that uses the rt2x00 driver,
 which I believe is mac80211. That system doesn't have this problem,
 which leads me to believe it may not be mac80211 after all, although I
 wouldn't rule it out.


This also doesn't seem to be related to firmware version. I forced my
device to use b43legacy, and the results were identical with the
version 3 firmware.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers/scsi/: Spelling fixes

2007-12-17 Thread James Smart



On Mon, 17 Dec 2007, Joe Perches wrote:


Signed-off-by: Joe Perches [EMAIL PROTECTED]
---
 drivers/scsi/NCR53C9x.h   |2 +-
 drivers/scsi/aic7xxx/aic79xx_inline.h |2 +-
 drivers/scsi/aic7xxx/aic79xx_osm.c|2 +-
 drivers/scsi/aic7xxx/aic79xx_pci.c|4 ++--
 drivers/scsi/aic7xxx/aic7xxx_inline.h |2 +-
 drivers/scsi/aic7xxx/aic7xxx_osm.c|2 +-
 drivers/scsi/ipr.c|2 +-
 drivers/scsi/ips.c|2 +-
 drivers/scsi/iscsi_tcp.c  |4 ++--
 drivers/scsi/lpfc/lpfc.h  |2 +-
 drivers/scsi/lpfc/lpfc_mbox.c |2 +-
 drivers/scsi/megaraid/megaraid_mbox.c |   10 +-
 drivers/scsi/psi240i.c|2 +-
 drivers/scsi/qla2xxx/qla_gs.c |2 +-


For the lpfc bits:

Acked-by: James Smart [EMAIL PROTECTED]

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: soft lockup - CPU#1 stuck for 15s! [swapper:0]

2007-12-17 Thread Thomas Gleixner

On Mon, 17 Dec 2007, Parag Warudkar wrote:
 On Dec 17, 2007 3:05 AM, Thomas Gleixner [EMAIL PROTECTED] wrote:
  Sigh. You did not have the debug patch applied anymore, which printks
  the timer_list data ? Can you apply it again and provide the output
  please ?
 
 
 This keeps getting more and more weird - This time I was running with
 CONFIG_CPU_IDLE=N and I have ton of soft lockups after 14hr uptime.

It's more than weird.
 
 now at 39080147128907 nsecs

   .idle_entrytime : 39080384013047 nsecs

The time, when we entered idle on CPU#0 is in the future. 

   .tick_stopped   : 0

But the tick is not stopped, that means CPU#0 has work to do

On CPU#1 idle entry just happened:

   .idle_entrytime : 39079996603653 nsecs

 now at 40490254040892 nsecs

   .idle_entrytime : 40490492012833 nsecs

Again, idle_entry on CPU#0 is in the future.

On CPU#1 the idle entry was at: 
   .idle_entrytime : 40489996578090 nsecs

which means: 0.257462802 sec. ago

 now at 40700144217096 nsecs

Aarg. On CPU#0 this is consistently in the future:

   .idle_entrytime : 40700372012887 nsecs

I'm really confused.

   .idle_entrytime : 4066620694 nsecs
   .idle_sleeptime : 40540536046589 nsecs
   .last_jiffies   : 1010
   .next_jiffies   : 10100467
   .idle_expires   : 4070186400 nsecs
 jiffies: 10100158
 
 
 Tick Device: mode: 1
 Clock Event Device: hpet
  max_delta_ns:   2147483647
  min_delta_ns:   3352
  mult:   61496110
  shift:  32
  mode:   3
  next_event: 4070069200 nsecs
  set_next_event: hpet_legacy_next_event
  set_mode:   hpet_legacy_set_mode
  event_handler:  tick_handle_oneshot_broadcast
 tick_broadcast_mask: 0003

Here is the next inconsistent data:

 tick_broadcast_oneshot_mask: 0003

CPU#1 just woke up. That means the broadcast oneshot mask must be
cleared for CPU#1.

Some real strange thing is going on in your box.

I try to come up with some more debug patches tomorrow.

  tglx
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: FInal kprobes rollup patches

2007-12-17 Thread Harvey Harrison

On Mon, 2007-12-17 at 16:52 -0500, Masami Hiramatsu wrote:
 Hi Harvey,
 Before porting, could you tell me what differences are important
 to you? We can discuss about it.
 
  I just sent out a series of 4 patches equivalent to your patches 1-4/6
  but based on my already unified kprobes.c/h, You may want to check your
  handling of restored registers in trampoline_probe_handler which I found
  when rebasing yours on top of my cleanups.  Not sure if this is
  important, but it was a difference I found.
  
  X86_32:
  regs-cs = __KERNEL_CS | get_kernel_rpl();
  
  yours:
  regs-cs = __KERNEL_CS;
 
 Because of kretprobe's compatibility, on x86-32 cs should be set rpl().
 But get_kernel_rpl() does not exist on x86-64.
 

I've already ported it and sent it to you.  It's not really important to
me I just think my fine-grained patches may be of some use to see where
the differences between X86_32/64 ended up being.  Your patches end up
being just about entirely removal of ifdefs when rebased onto my
patches, so it's at least a good secondary check of your patches even
if mine don't go in.  Your patches end up being much smaller against
my version too.

I like my version slightly better because the remaining ifdefs (wrmsr,
etc) and others could be done in a few more small patches that are more
easily reviewable than your large final unification patch.

But, you know the code better than I

Harvey

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: cpuinfo_cur_freq always max

2007-12-17 Thread Johannes Weiner

Hi,

Stephen Clark [EMAIL PROTECTED] writes:

Which governor are you using?  ondemand?
 Not sure - but the only thing that is changed is the kernel - if I go
 back to 2.6.23.1 it works correctly.

Have a look at /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Hannes

PS: Steve, please keep the list in CC.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PCI: fix for quirk_e100_interrupt()

2007-12-17 Thread Kok, Auke

Ivan Kokshaysky wrote:
 Check that the e100 is in the D0 power state. If it's not, it won't
 respond to MMIO accesses and we end up with master-abort machine
 checks on some platforms.
 
 Signed-off-by: Ivan Kokshaysky [EMAIL PROTECTED]

what kind of platform actually is doing this? It almost seems like something is
wrong with that platform's BIOS and I wonder if this workaround should not be 
more
general (IOW is it not just e100 that is affected but other components as well?)

Auke


 ---
  drivers/pci/quirks.c |   14 +-
  1 files changed, 13 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
 index 26cc4dc..c8b2b9d 100644
 --- a/drivers/pci/quirks.c
 +++ b/drivers/pci/quirks.c
 @@ -1406,9 +1406,10 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NETMOS, 
 PCI_ANY_ID, quirk_netmos);
  
  static void __devinit quirk_e100_interrupt(struct pci_dev *dev)
  {
 - u16 command;
 + u16 command, pmcsr;
   u8 __iomem *csr;
   u8 cmd_hi;
 + int pm;
  
   switch (dev-device) {
   /* PCI IDs taken from drivers/net/e100.c */
 @@ -1442,6 +1443,17 @@ static void __devinit quirk_e100_interrupt(struct 
 pci_dev *dev)
   if (!(command  PCI_COMMAND_MEMORY) || !pci_resource_start(dev, 0))
   return;
  
 + /*
 +  * Check that the device is in the D0 power state. If it's not,
 +  * there is no point to look any further.
 +  */
 + pm = pci_find_capability(dev, PCI_CAP_ID_PM);
 + if (pm) {
 + pci_read_config_word(dev, pm + PCI_PM_CTRL, pmcsr);
 + if ((pmcsr  PCI_PM_CTRL_STATE_MASK) != PCI_D0)
 + return;
 + }
 +
   /* Convert from PCI bus to resource space.  */
   csr = ioremap(pci_resource_start(dev, 0), 8);
   if (!csr) {
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

2007-12-17 Thread David P. Reed

Besides the two reports of freezes on bugzilla.kernel.org (9511, 6307), 
the following two bug reports on bugzilla.redhat.com are almost 
certainly due to the same cause (imo, of course): 245834, 227234.


Ubuntu launchpad bug 158849 also seems to report the same problem, for 
an HP dv6258se 64-bit machine.


Also this one: 
http://www.mail-archive.com/[EMAIL PROTECTED]/msg10321.html


If you want to collect dmidecode data from these folks, perhaps we might 
get a wider sense of what categories of machines are affected.  They all 
seem to be recemt HP and Compaq AMD64 laptops, probably all Quanta 
motherboards.



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

< 1 2 3 4 5 6 7 8 9 10 >

301 - 400 of 1228 matches

Mail list logo