* [lm-sensors] Problems with i2c_i801
From: James Davis @ 2006-03-31 10:28 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <1143796746.10346.10.camel@cressida.cert>
On Fri, 2006-03-31 at 12:15 +0200, Jean Delvare wrote:
> Where do the "sensors" program come from? Debian package?
> Hand-compiled? Which version ("sensors -v")?
The Debian package
cressida:/home/james# sensors -v
sensors version 2.10.0 with libsensors version 2.10.0
> Note that no hardware monitoring chip was detected on your system, so
> if that's what you are after, fixing the problem above won't help you
> much. Either your system has no hardware monitoring chip, or
> sensors-detect failed to detect it for some reason. The complete output
> of "sensors-detect" may let us help you in the second case.
cressida:/home/james# sensors-detect
# sensors-detect revision 1.413 (2006/01/19 20:28:00)
This program will help you determine which I2C/SMBus modules you need to
load to use lm_sensors most effectively. You need to have i2c and
lm_sensors installed before running this program.
Also, you need to be `root', or at least have access to the /dev/i2c-*
files, for most things.
If you have patched your kernel and have some drivers built in, you can
safely answer NO if asked to load some modules. In this case, things may
seem a bit confusing, but they will still work.
It is generally safe and recommended to accept the default answers to
all
questions, unless you know what you're doing.
We can start with probing for (PCI) I2C or SMBus adapters.
You do not need any special privileges for this.
Do you want to probe now? (YES/no):
Probing for PCI bus adapters...
Use driver `i2c-i801' for device 00:1f.3: Intel 82801FB ICH6
Probe succesfully concluded.
We will now try to load each adapter module in turn.
Module `i2c-i801' already loaded.
If you have undetectable or unsupported adapters, you can have them
scanned by manually loading the modules before running this script.
To continue, we need module `i2c-dev' to be loaded.
If it is built-in into your kernel, you can safely skip this.
i2c-dev is already loaded.
We are now going to do the adapter probings. Some adapters may hang
halfway
through; we can't really help that. Also, some chips will be double
detected;
we choose the one with the highest confidence value in that case.
If you found that the adapter hung after probing a certain address, you
can
specify that address to remain unprobed. That often
includes address 0x69 (clock chip).
Next adapter: SMBus I801 adapter at e8a0
Do you want to scan it? (YES/no/selectively):
Client found at address 0x08
Client found at address 0x30
Client found at address 0x32
Client found at address 0x44
Probing for `Maxim MAX6633/MAX6634/MAX6635'... Failed!
Client at address 0x50 can not be probed - unload all client drivers
first!
Client at address 0x52 can not be probed - unload all client drivers
first!
Client found at address 0x69
Some chips are also accessible through the ISA bus. ISA probes are
typically a bit more dangerous, as we have to write to I/O ports to do
this. This is usually safe though.
Do you want to scan the ISA bus? (YES/no):
Probing for `National Semiconductor LM78'
Trying address 0x0290... Failed!
Probing for `National Semiconductor LM78-J'
Trying address 0x0290... Failed!
Probing for `National Semiconductor LM79'
Trying address 0x0290... Failed!
Probing for `Winbond W83781D'
Trying address 0x0290... Failed!
Probing for `Winbond W83782D'
Trying address 0x0290... Failed!
Probing for `Winbond W83627HF'
Trying address 0x0290... Failed!
Probing for `Winbond W83627EHF'
Trying address 0x0290... Failed!
Probing for `Silicon Integrated Systems SIS5595'
Trying general detect... Failed!
Probing for `VIA Technologies VT82C686 Integrated Sensors'
Trying general detect... Failed!
Probing for `VIA Technologies VT8231 Integrated Sensors'
Trying general detect... Failed!
Probing for `ITE IT8712F'
Trying address 0x0290... Failed!
Probing for `ITE IT8705F / SiS 950'
Trying address 0x0290... Failed!
Probing for `IPMI BMC KCS'
Trying address 0x0ca0... Failed!
Probing for `IPMI BMC SMIC'
Trying address 0x0ca8... Failed!
Some Super I/O chips may also contain sensors. Super I/O probes are
typically a bit more dangerous, as we have to write to I/O ports to do
this. This is usually safe though.
Do you want to scan for Super I/O sensors? (YES/no):
Probing for `ITE 8702F Super IO Sensors'
Failed! (0x7601)
Probing for `ITE 8705F Super IO Sensors'
Failed! (0x7601)
Probing for `ITE 8712F Super IO Sensors'
Failed! (0x7601)
Probing for `Nat. Semi. PC87351 Super IO Fan Sensors'
Failed! (0x76)
Probing for `Nat. Semi. PC87360 Super IO Fan Sensors'
Failed! (0x76)
Probing for `Nat. Semi. PC87363 Super IO Fan Sensors'
Failed! (0x76)
Probing for `Nat. Semi. PC87364 Super IO Fan Sensors'
Failed! (0x76)
Probing for `Nat. Semi. PC87365 Super IO Fan Sensors'
Failed! (0x76)
Probing for `Nat. Semi. PC87365 Super IO Voltage Sensors'
Failed! (0x76)
Probing for `Nat. Semi. PC87365 Super IO Thermal Sensors'
Failed! (0x76)
Probing for `Nat. Semi. PC87366 Super IO Fan Sensors'
Failed! (0x76)
Probing for `Nat. Semi. PC87366 Super IO Voltage Sensors'
Failed! (0x76)
Probing for `Nat. Semi. PC87366 Super IO Thermal Sensors'
Failed! (0x76)
Probing for `Nat. Semi. PC87372 Super IO Fan Sensors'
Failed! (0x76)
Probing for `Nat. Semi. PC87373 Super IO Fan Sensors'
Failed! (0x76)
Probing for `Nat. Semi. PC87591 Super IO'
Failed! (0x76)
Probing for `Nat. Semi. PC87371 Super IO'
Failed! (0x76)
Probing for `Nat. Semi. PC97371 Super IO'
Failed! (0x76)
Probing for `Nat. Semi. PC8739x Super IO'
Failed! (0x76)
Probing for `Nat. Semi. PC8741x Super IO'
Failed! (0x76)
Probing for `Nat. Semi. PCPC87427 Super IO'
Failed! (0x76)
Probing for `SMSC 47B27x Super IO Fan Sensors'
Failed! (0x76)
Probing for `SMSC 47M10x/13x Super IO Fan Sensors'
Failed! (0x76)
Probing for `SMSC 47M14x Super IO Fan Sensors'
Failed! (0x76)
Probing for `SMSC 47M15x/192/997 Super IO Fan Sensors'
Failed! (0x76)
Probing for `SMSC 47S42x Super IO Fan Sensors'
Failed! (0x76)
Probing for `SMSC 47S45x Super IO Fan Sensors'
Failed! (0x76)
Probing for `SMSC 47M172 Super IO'
Failed! (0x76)
Probing for `SMSC LPC47B397-NC Super IO'
Failed! (0x76)
Probing for `SMSC SCH5307-NS Super IO'
Failed! (0x76)
Probing for `VT1211 Super IO Sensors'
Failed! (skipping family)
Probing for `Winbond W83627EHF/EHG Super IO Sensors'
Failed! (skipping family)
Do you want to scan for secondary Super I/O sensors? (YES/no):
Probing for `ITE 8702F Super IO Sensors'
Failed! (skipping family)
Probing for `Nat. Semi. PC87351 Super IO Fan Sensors'
Failed! (skipping family)
Probing for `SMSC 47B27x Super IO Fan Sensors'
Failed! (skipping family)
Probing for `VT1211 Super IO Sensors'
Failed! (skipping family)
Probing for `Winbond W83627EHF/EHG Super IO Sensors'
Failed! (skipping family)
Sorry, no chips were detected.
Either your sensors are not supported, or they are
connected to an I2C bus adapter that we do not support.
See doc/FAQ, doc/lm_sensors-FAQ.html, or
http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/doc/lm_sensors-FAQ.html
(FAQ #4.24.3) for further information.
If you find out what chips are on your board, see
http://secure.netroedge.com/~lm78/newdrivers.html for driver status.
:-( doesn't look hopeful.
James
^ permalink raw reply
* Re: [NETFILTER 00/04]: Netfilter Update
From: Patrick McHardy @ 2006-03-31 10:28 UTC (permalink / raw)
To: David S. Miller; +Cc: netfilter-devel
In-Reply-To: <20060331.021518.94936868.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]
David S. Miller wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Fri, 31 Mar 2006 03:09:05 +0200 (MEST)
>
>
>>Yasuyuki Kozakai:
>> [NETFILTER]: x_tables: unify IPv4/IPv6 multiport match
>
>
> This first patch didn't apply, so I'm going to pass on all of these
> until you figure out what's wrong here.
>
> The problem is the net/ipv6/netfilter/Makefile hunk.
>
> @@ -10,7 +10,6 @@ obj-$(CONFIG_IP6_NF_MATCH_IPV6HEADER) +=
> obj-$(CONFIG_IP6_NF_MATCH_FRAG) += ip6t_frag.o
> obj-$(CONFIG_IP6_NF_MATCH_AH) += ip6t_ah.o
> obj-$(CONFIG_IP6_NF_MATCH_EUI64) += ip6t_eui64.o
> -obj-$(CONFIG_IP6_NF_MATCH_MULTIPORT) += ip6t_multiport.o
>
> in my current tree the ip6t_ah.o line instead reads as:
>
> obj-$(CONFIG_IP6_NF_MATCH_AHESP) += ip6t_esp.o ip6t_ah.o
>
> It seems something is wrong with the tree you generated these
> patches against.
>
> Please resubmit once you've fixed this, thanks.
Sorry, I accidentally missed the first patch. I've attached it to
this mail, with it the patches apply cleanly against the current tree.
If you want me to resubmit the entire set anyway please say so.
Thanks.
[-- Attachment #2: 01.diff --]
[-- Type: text/plain, Size: 16830 bytes --]
[NETFILTER]: x_tables: unify IPv4/IPv6 esp match
This unifies ipt_esp and ip6t_esp to xt_esp. Please note that now
a user program needs to specify IPPROTO_ESP as protocol to use esp match
with IPv6. This means that ip6tables requires '-p esp' like iptables.
Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp>
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit 6b0b3ab9f047358723d8b3116b71318f64088a1a
tree 0e8d7dcd24ee91e251d8451a7dec51eed50ea338
parent 91b9a1a505eb4b947318aaba4aed65fec9ccc88b
author Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Wed, 29 Mar 2006 10:05:53 +0200
committer Patrick McHardy <kaber@trash.net> Wed, 29 Mar 2006 10:05:53 +0200
include/linux/netfilter/xt_esp.h | 14 +++
include/linux/netfilter_ipv4/ipt_esp.h | 14 +--
include/linux/netfilter_ipv6/ip6t_esp.h | 12 +--
net/ipv4/netfilter/Kconfig | 8 +-
net/ipv4/netfilter/Makefile | 2
net/ipv4/netfilter/ipt_esp.c | 111 -------------------------
net/ipv6/netfilter/Kconfig | 6 +
net/ipv6/netfilter/Makefile | 2
net/ipv6/netfilter/ip6t_esp.c | 115 --------------------------
net/netfilter/Kconfig | 9 ++
net/netfilter/Makefile | 1
net/netfilter/xt_esp.c | 136 +++++++++++++++++++++++++++++++
12 files changed, 177 insertions(+), 253 deletions(-)
diff --git a/include/linux/netfilter/xt_esp.h b/include/linux/netfilter/xt_esp.h
new file mode 100644
index 0000000..9380fb1
--- /dev/null
+++ b/include/linux/netfilter/xt_esp.h
@@ -0,0 +1,14 @@
+#ifndef _XT_ESP_H
+#define _XT_ESP_H
+
+struct xt_esp
+{
+ u_int32_t spis[2]; /* Security Parameter Index */
+ u_int8_t invflags; /* Inverse flags */
+};
+
+/* Values for "invflags" field in struct xt_esp. */
+#define XT_ESP_INV_SPI 0x01 /* Invert the sense of spi. */
+#define XT_ESP_INV_MASK 0x01 /* All possible flags. */
+
+#endif /*_XT_ESP_H*/
diff --git a/include/linux/netfilter_ipv4/ipt_esp.h b/include/linux/netfilter_ipv4/ipt_esp.h
index c782a83..78296e7 100644
--- a/include/linux/netfilter_ipv4/ipt_esp.h
+++ b/include/linux/netfilter_ipv4/ipt_esp.h
@@ -1,16 +1,10 @@
#ifndef _IPT_ESP_H
#define _IPT_ESP_H
-struct ipt_esp
-{
- u_int32_t spis[2]; /* Security Parameter Index */
- u_int8_t invflags; /* Inverse flags */
-};
+#include <linux/netfilter/xt_esp.h>
-
-
-/* Values for "invflags" field in struct ipt_esp. */
-#define IPT_ESP_INV_SPI 0x01 /* Invert the sense of spi. */
-#define IPT_ESP_INV_MASK 0x01 /* All possible flags. */
+#define ipt_esp xt_esp
+#define IPT_ESP_INV_SPI XT_ESP_INV_SPI
+#define IPT_ESP_INV_MASK XT_ESP_INV_MASK
#endif /*_IPT_ESP_H*/
diff --git a/include/linux/netfilter_ipv6/ip6t_esp.h b/include/linux/netfilter_ipv6/ip6t_esp.h
index a91b6ab..f62eaf5 100644
--- a/include/linux/netfilter_ipv6/ip6t_esp.h
+++ b/include/linux/netfilter_ipv6/ip6t_esp.h
@@ -1,14 +1,10 @@
#ifndef _IP6T_ESP_H
#define _IP6T_ESP_H
-struct ip6t_esp
-{
- u_int32_t spis[2]; /* Security Parameter Index */
- u_int8_t invflags; /* Inverse flags */
-};
+#include <linux/netfilter/xt_esp.h>
-/* Values for "invflags" field in struct ip6t_esp. */
-#define IP6T_ESP_INV_SPI 0x01 /* Invert the sense of spi. */
-#define IP6T_ESP_INV_MASK 0x01 /* All possible flags. */
+#define ip6t_esp xt_esp
+#define IP6T_ESP_INV_SPI XT_ESP_INV_SPI
+#define IP6T_ESP_INV_MASK XT_ESP_INV_MASK
#endif /*_IP6T_ESP_H*/
diff --git a/net/ipv4/netfilter/Kconfig b/net/ipv4/netfilter/Kconfig
index 882b842..ebbd644 100644
--- a/net/ipv4/netfilter/Kconfig
+++ b/net/ipv4/netfilter/Kconfig
@@ -272,12 +272,12 @@ config IP_NF_MATCH_DSCP
To compile it as a module, choose M here. If unsure, say N.
-config IP_NF_MATCH_AH_ESP
- tristate "AH/ESP match support"
+config IP_NF_MATCH_AH
+ tristate "AH match support"
depends on IP_NF_IPTABLES
help
- These two match extensions (`ah' and `esp') allow you to match a
- range of SPIs inside AH or ESP headers of IPSec packets.
+ This match extension allows you to match a range of SPIs
+ inside AH header of IPSec packets.
To compile it as a module, choose M here. If unsure, say N.
diff --git a/net/ipv4/netfilter/Makefile b/net/ipv4/netfilter/Makefile
index f2cd9a6..09ae167 100644
--- a/net/ipv4/netfilter/Makefile
+++ b/net/ipv4/netfilter/Makefile
@@ -59,7 +59,7 @@ obj-$(CONFIG_IP_NF_MATCH_TOS) += ipt_tos
obj-$(CONFIG_IP_NF_MATCH_RECENT) += ipt_recent.o
obj-$(CONFIG_IP_NF_MATCH_ECN) += ipt_ecn.o
obj-$(CONFIG_IP_NF_MATCH_DSCP) += ipt_dscp.o
-obj-$(CONFIG_IP_NF_MATCH_AH_ESP) += ipt_ah.o ipt_esp.o
+obj-$(CONFIG_IP_NF_MATCH_AH) += ipt_ah.o
obj-$(CONFIG_IP_NF_MATCH_TTL) += ipt_ttl.o
obj-$(CONFIG_IP_NF_MATCH_ADDRTYPE) += ipt_addrtype.o
diff --git a/net/ipv4/netfilter/ipt_esp.c b/net/ipv4/netfilter/ipt_esp.c
deleted file mode 100644
index 3840b41..0000000
--- a/net/ipv4/netfilter/ipt_esp.c
+++ /dev/null
@@ -1,111 +0,0 @@
-/* Kernel module to match ESP parameters. */
-
-/* (C) 1999-2000 Yon Uriarte <yon@astaro.de>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include <linux/module.h>
-#include <linux/skbuff.h>
-#include <linux/ip.h>
-
-#include <linux/netfilter_ipv4/ipt_esp.h>
-#include <linux/netfilter_ipv4/ip_tables.h>
-
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Yon Uriarte <yon@astaro.de>");
-MODULE_DESCRIPTION("iptables ESP SPI match module");
-
-#ifdef DEBUG_CONNTRACK
-#define duprintf(format, args...) printk(format , ## args)
-#else
-#define duprintf(format, args...)
-#endif
-
-/* Returns 1 if the spi is matched by the range, 0 otherwise */
-static inline int
-spi_match(u_int32_t min, u_int32_t max, u_int32_t spi, int invert)
-{
- int r=0;
- duprintf("esp spi_match:%c 0x%x <= 0x%x <= 0x%x",invert? '!':' ',
- min,spi,max);
- r=(spi >= min && spi <= max) ^ invert;
- duprintf(" result %s\n",r? "PASS" : "FAILED");
- return r;
-}
-
-static int
-match(const struct sk_buff *skb,
- const struct net_device *in,
- const struct net_device *out,
- const struct xt_match *match,
- const void *matchinfo,
- int offset,
- unsigned int protoff,
- int *hotdrop)
-{
- struct ip_esp_hdr _esp, *eh;
- const struct ipt_esp *espinfo = matchinfo;
-
- /* Must not be a fragment. */
- if (offset)
- return 0;
-
- eh = skb_header_pointer(skb, protoff,
- sizeof(_esp), &_esp);
- if (eh == NULL) {
- /* We've been asked to examine this packet, and we
- * can't. Hence, no choice but to drop.
- */
- duprintf("Dropping evil ESP tinygram.\n");
- *hotdrop = 1;
- return 0;
- }
-
- return spi_match(espinfo->spis[0], espinfo->spis[1],
- ntohl(eh->spi),
- !!(espinfo->invflags & IPT_ESP_INV_SPI));
-}
-
-/* Called when user tries to insert an entry of this type. */
-static int
-checkentry(const char *tablename,
- const void *ip_void,
- const struct xt_match *match,
- void *matchinfo,
- unsigned int matchinfosize,
- unsigned int hook_mask)
-{
- const struct ipt_esp *espinfo = matchinfo;
-
- /* Must specify no unknown invflags */
- if (espinfo->invflags & ~IPT_ESP_INV_MASK) {
- duprintf("ipt_esp: unknown flags %X\n", espinfo->invflags);
- return 0;
- }
- return 1;
-}
-
-static struct ipt_match esp_match = {
- .name = "esp",
- .match = match,
- .matchsize = sizeof(struct ipt_esp),
- .proto = IPPROTO_ESP,
- .checkentry = checkentry,
- .me = THIS_MODULE,
-};
-
-static int __init ipt_esp_init(void)
-{
- return ipt_register_match(&esp_match);
-}
-
-static void __exit ipt_esp_fini(void)
-{
- ipt_unregister_match(&esp_match);
-}
-
-module_init(ipt_esp_init);
-module_exit(ipt_esp_fini);
diff --git a/net/ipv6/netfilter/Kconfig b/net/ipv6/netfilter/Kconfig
index 98f7875..bdd569f 100644
--- a/net/ipv6/netfilter/Kconfig
+++ b/net/ipv6/netfilter/Kconfig
@@ -115,11 +115,11 @@ config IP6_NF_MATCH_IPV6HEADER
To compile it as a module, choose M here. If unsure, say N.
-config IP6_NF_MATCH_AHESP
- tristate "AH/ESP match support"
+config IP6_NF_MATCH_AH
+ tristate "AH match support"
depends on IP6_NF_IPTABLES
help
- This module allows one to match AH and ESP packets.
+ This module allows one to match AH packets.
To compile it as a module, choose M here. If unsure, say N.
diff --git a/net/ipv6/netfilter/Makefile b/net/ipv6/netfilter/Makefile
index 8436a1a..c387170 100644
--- a/net/ipv6/netfilter/Makefile
+++ b/net/ipv6/netfilter/Makefile
@@ -8,7 +8,7 @@ obj-$(CONFIG_IP6_NF_MATCH_RT) += ip6t_rt
obj-$(CONFIG_IP6_NF_MATCH_OPTS) += ip6t_hbh.o ip6t_dst.o
obj-$(CONFIG_IP6_NF_MATCH_IPV6HEADER) += ip6t_ipv6header.o
obj-$(CONFIG_IP6_NF_MATCH_FRAG) += ip6t_frag.o
-obj-$(CONFIG_IP6_NF_MATCH_AHESP) += ip6t_esp.o ip6t_ah.o
+obj-$(CONFIG_IP6_NF_MATCH_AH) += ip6t_ah.o
obj-$(CONFIG_IP6_NF_MATCH_EUI64) += ip6t_eui64.o
obj-$(CONFIG_IP6_NF_MATCH_MULTIPORT) += ip6t_multiport.o
obj-$(CONFIG_IP6_NF_MATCH_OWNER) += ip6t_owner.o
diff --git a/net/ipv6/netfilter/ip6t_esp.c b/net/ipv6/netfilter/ip6t_esp.c
deleted file mode 100644
index 36bedad..0000000
--- a/net/ipv6/netfilter/ip6t_esp.c
+++ /dev/null
@@ -1,115 +0,0 @@
-/* Kernel module to match ESP parameters. */
-/* (C) 2001-2002 Andras Kis-Szabo <kisza@sch.bme.hu>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-
-#include <linux/module.h>
-#include <linux/skbuff.h>
-#include <linux/ip.h>
-#include <linux/ipv6.h>
-#include <linux/types.h>
-#include <net/checksum.h>
-#include <net/ipv6.h>
-
-#include <linux/netfilter_ipv6/ip6_tables.h>
-#include <linux/netfilter_ipv6/ip6t_esp.h>
-
-MODULE_LICENSE("GPL");
-MODULE_DESCRIPTION("IPv6 ESP match");
-MODULE_AUTHOR("Andras Kis-Szabo <kisza@sch.bme.hu>");
-
-#if 0
-#define DEBUGP printk
-#else
-#define DEBUGP(format, args...)
-#endif
-
-/* Returns 1 if the spi is matched by the range, 0 otherwise */
-static inline int
-spi_match(u_int32_t min, u_int32_t max, u_int32_t spi, int invert)
-{
- int r=0;
- DEBUGP("esp spi_match:%c 0x%x <= 0x%x <= 0x%x",invert? '!':' ',
- min,spi,max);
- r=(spi >= min && spi <= max) ^ invert;
- DEBUGP(" result %s\n",r? "PASS\n" : "FAILED\n");
- return r;
-}
-
-static int
-match(const struct sk_buff *skb,
- const struct net_device *in,
- const struct net_device *out,
- const struct xt_match *match,
- const void *matchinfo,
- int offset,
- unsigned int protoff,
- int *hotdrop)
-{
- struct ip_esp_hdr _esp, *eh;
- const struct ip6t_esp *espinfo = matchinfo;
- unsigned int ptr;
-
- /* Make sure this isn't an evil packet */
- /*DEBUGP("ipv6_esp entered \n");*/
-
- if (ipv6_find_hdr(skb, &ptr, NEXTHDR_ESP, NULL) < 0)
- return 0;
-
- eh = skb_header_pointer(skb, ptr, sizeof(_esp), &_esp);
- if (eh == NULL) {
- *hotdrop = 1;
- return 0;
- }
-
- DEBUGP("IPv6 ESP SPI %u %08X\n", ntohl(eh->spi), ntohl(eh->spi));
-
- return (eh != NULL)
- && spi_match(espinfo->spis[0], espinfo->spis[1],
- ntohl(eh->spi),
- !!(espinfo->invflags & IP6T_ESP_INV_SPI));
-}
-
-/* Called when user tries to insert an entry of this type. */
-static int
-checkentry(const char *tablename,
- const void *ip,
- const struct xt_match *match,
- void *matchinfo,
- unsigned int matchinfosize,
- unsigned int hook_mask)
-{
- const struct ip6t_esp *espinfo = matchinfo;
-
- if (espinfo->invflags & ~IP6T_ESP_INV_MASK) {
- DEBUGP("ip6t_esp: unknown flags %X\n",
- espinfo->invflags);
- return 0;
- }
- return 1;
-}
-
-static struct ip6t_match esp_match = {
- .name = "esp",
- .match = match,
- .matchsize = sizeof(struct ip6t_esp),
- .checkentry = checkentry,
- .me = THIS_MODULE,
-};
-
-static int __init ip6t_esp_init(void)
-{
- return ip6t_register_match(&esp_match);
-}
-
-static void __exit ip6t_esp_fini(void)
-{
- ip6t_unregister_match(&esp_match);
-}
-
-module_init(ip6t_esp_init);
-module_exit(ip6t_esp_fini);
diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index 332acb3..5fe5189 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -231,6 +231,15 @@ config NETFILTER_XT_MATCH_DCCP
If you want to compile it as a module, say M here and read
<file:Documentation/modules.txt>. If unsure, say `N'.
+config NETFILTER_XT_MATCH_ESP
+ tristate '"ESP" match support'
+ depends on NETFILTER_XTABLES
+ help
+ This match extension allows you to match a range of SPIs
+ inside ESP header of IPSec packets.
+
+ To compile it as a module, choose M here. If unsure, say N.
+
config NETFILTER_XT_MATCH_HELPER
tristate '"helper" match support'
depends on NETFILTER_XTABLES
diff --git a/net/netfilter/Makefile b/net/netfilter/Makefile
index 9558727..8f02486 100644
--- a/net/netfilter/Makefile
+++ b/net/netfilter/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_NETFILTER_XT_MATCH_CONNBYTE
obj-$(CONFIG_NETFILTER_XT_MATCH_CONNMARK) += xt_connmark.o
obj-$(CONFIG_NETFILTER_XT_MATCH_CONNTRACK) += xt_conntrack.o
obj-$(CONFIG_NETFILTER_XT_MATCH_DCCP) += xt_dccp.o
+obj-$(CONFIG_NETFILTER_XT_MATCH_ESP) += xt_esp.o
obj-$(CONFIG_NETFILTER_XT_MATCH_HELPER) += xt_helper.o
obj-$(CONFIG_NETFILTER_XT_MATCH_LENGTH) += xt_length.o
obj-$(CONFIG_NETFILTER_XT_MATCH_LIMIT) += xt_limit.o
diff --git a/net/netfilter/xt_esp.c b/net/netfilter/xt_esp.c
new file mode 100644
index 0000000..9dad628
--- /dev/null
+++ b/net/netfilter/xt_esp.c
@@ -0,0 +1,136 @@
+/* Kernel module to match ESP parameters. */
+
+/* (C) 1999-2000 Yon Uriarte <yon@astaro.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/skbuff.h>
+#include <linux/in.h>
+#include <linux/ip.h>
+
+#include <linux/netfilter/xt_esp.h>
+#include <linux/netfilter/x_tables.h>
+
+#include <linux/netfilter_ipv4/ip_tables.h>
+#include <linux/netfilter_ipv6/ip6_tables.h>
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Yon Uriarte <yon@astaro.de>");
+MODULE_DESCRIPTION("x_tables ESP SPI match module");
+MODULE_ALIAS("ipt_esp");
+MODULE_ALIAS("ip6t_esp");
+
+#if 0
+#define duprintf(format, args...) printk(format , ## args)
+#else
+#define duprintf(format, args...)
+#endif
+
+/* Returns 1 if the spi is matched by the range, 0 otherwise */
+static inline int
+spi_match(u_int32_t min, u_int32_t max, u_int32_t spi, int invert)
+{
+ int r = 0;
+ duprintf("esp spi_match:%c 0x%x <= 0x%x <= 0x%x", invert ? '!' : ' ',
+ min, spi, max);
+ r = (spi >= min && spi <= max) ^ invert;
+ duprintf(" result %s\n", r ? "PASS" : "FAILED");
+ return r;
+}
+
+static int
+match(const struct sk_buff *skb,
+ const struct net_device *in,
+ const struct net_device *out,
+ const struct xt_match *match,
+ const void *matchinfo,
+ int offset,
+ unsigned int protoff,
+ int *hotdrop)
+{
+ struct ip_esp_hdr _esp, *eh;
+ const struct xt_esp *espinfo = matchinfo;
+
+ /* Must not be a fragment. */
+ if (offset)
+ return 0;
+
+ eh = skb_header_pointer(skb, protoff, sizeof(_esp), &_esp);
+ if (eh == NULL) {
+ /* We've been asked to examine this packet, and we
+ * can't. Hence, no choice but to drop.
+ */
+ duprintf("Dropping evil ESP tinygram.\n");
+ *hotdrop = 1;
+ return 0;
+ }
+
+ return spi_match(espinfo->spis[0], espinfo->spis[1], ntohl(eh->spi),
+ !!(espinfo->invflags & XT_ESP_INV_SPI));
+}
+
+/* Called when user tries to insert an entry of this type. */
+static int
+checkentry(const char *tablename,
+ const void *ip_void,
+ const struct xt_match *match,
+ void *matchinfo,
+ unsigned int matchinfosize,
+ unsigned int hook_mask)
+{
+ const struct xt_esp *espinfo = matchinfo;
+
+ if (espinfo->invflags & ~XT_ESP_INV_MASK) {
+ duprintf("xt_esp: unknown flags %X\n", espinfo->invflags);
+ return 0;
+ }
+
+ return 1;
+}
+
+static struct xt_match esp_match = {
+ .name = "esp",
+ .family = AF_INET,
+ .proto = IPPROTO_ESP,
+ .match = &match,
+ .matchsize = sizeof(struct xt_esp),
+ .checkentry = &checkentry,
+ .me = THIS_MODULE,
+};
+
+static struct xt_match esp6_match = {
+ .name = "esp",
+ .family = AF_INET6,
+ .proto = IPPROTO_ESP,
+ .match = &match,
+ .matchsize = sizeof(struct xt_esp),
+ .checkentry = &checkentry,
+ .me = THIS_MODULE,
+};
+
+static int __init xt_esp_init(void)
+{
+ int ret;
+ ret = xt_register_match(&esp_match);
+ if (ret)
+ return ret;
+
+ ret = xt_register_match(&esp6_match);
+ if (ret)
+ xt_unregister_match(&esp_match);
+
+ return ret;
+}
+
+static void __exit xt_esp_cleanup(void)
+{
+ xt_unregister_match(&esp_match);
+ xt_unregister_match(&esp6_match);
+}
+
+module_init(xt_esp_init);
+module_exit(xt_esp_cleanup);
^ permalink raw reply related
* Re: Recommendations for supported 4-port SATA PCI card ?
From: Joshua Baker-LePain @ 2006-03-31 10:29 UTC (permalink / raw)
To: Mark Hahn; +Cc: linux-raid
In-Reply-To: <Pine.LNX.4.44.0603302227150.18644-100000@coffee.psychology.mcmaster.ca>
On Thu, 30 Mar 2006 at 10:38pm, Mark Hahn wrote
> before the 9550, I never found attractive in price/performance:
> expensive as hell and a lot slower than MD. but the 9550 is really
> quite impressive...
I like the 3wares for their ability to do true hot swap in hardware RAID
mode. I have 2 older servers with 7500 cards in 'em that I recently tried
to migrate to md (for speed, as you mentioned). All my testing with
'mdadm --fail' went just fine. However, when a disk actually died and the
3ware booted it, the server hung. So I migrated 'em back to hardware
RAID (but RAID10 instead of RAID5).
--
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University
^ permalink raw reply
* Re: [PATCH/RFC] libata: disable interrupts before soft reset
From: Tejun Heo @ 2006-03-31 10:32 UTC (permalink / raw)
To: albertl; +Cc: Jeff Garzik, Doug Maxey, IDE Linux
In-Reply-To: <442CFE96.1040203@tw.ibm.com>
On Fri, Mar 31, 2006 at 06:04:06PM +0800, Albert Lee wrote:
> Changes:
> - add ata_irq_off() to libata.h
> - call ata_irq_off() to disable the interrupt before soft reset
>
> Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
> ---
>
> When testing an old 1996 Acer 8x CD-ROM drive (CD-787E), an
> interrupt is generated in ata_devchk(), right after the device is selected.
> (The unhandled irq cause the IRQ 10 to be disabled.)
>
> Disabling interrupts before doing soft reset fixes the problem.
> However, this problem is only seen on the specific CD-ROM drive.
> So, don't know whether the fix is necessary.
>
> Patch against upstream (8b316a3973f05e572b4edeeda9072987f6bbaa44).
> For your review, thanks.
>
Hello, Albert.
Please hold this off. This issue is handled by new EH.
This problem is bigger than just during reset. Any error condition
which leaves the device and/or controller has potential to cause
similar problems or worse (e.g. data corruption, screaming
interrupts). New EH handles this by freezing ports when
device/controller enters unknown state. The controller is thawed
after EH reset is complete. The same mechanism applies to probing.
All ports are started frozen. Only after initial reset is complete,
ports get thawed.
It's been a loooooong week but I'm splitting the patches now. :)
--
tejun
^ permalink raw reply
* Re: [PATCH] cvsimport: use git-update-ref when updating
From: Eric Wong @ 2006-03-31 10:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0603311207270.20122@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 30 Mar 2006, Junio C Hamano wrote:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > This simplifies code, and also fixes a subtle bug: when importing in a
> > > shared repository, where another user last imported from CVS, cvsimport
> > > used to complain that it could not open <branch> for update.
> >
> > The second hunk look sensible but I do not know about "use Fcntl"
> > since I do not see anything you are adding that starts to use it...
>
> O_EXCL. Without "use Fcntl;" perl says I am not allowed to use bareword
> things in strict mode or some such.
Huh? I still don't see where O_EXCL is used.
> > > + system("git-update-ref refs/heads/$branch $cid") == 0
Passing args to system() in list form is always preferable in case
there's a shell-unfriendly variable:
system("git-update-ref", "refs/heads/$branch", $cid) == 0
--
Eric Wong
^ permalink raw reply
* Re: [NETFILTER 00/04]: Netfilter Update
From: David S. Miller @ 2006-03-31 10:32 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel
In-Reply-To: <442D0468.7080300@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Fri, 31 Mar 2006 12:28:56 +0200
> Sorry, I accidentally missed the first patch. I've attached it to
> this mail, with it the patches apply cleanly against the current tree.
> If you want me to resubmit the entire set anyway please say so.
> Thanks.
Ok, this is fine.
I already pushed to Linus tonight, so I'll add these in
some time tomorrow.
Thanks again.
^ permalink raw reply
* Re: [PATCH -rt] spin_lock in check_monotonic_clock must be raw
From: Ingo Molnar @ 2006-03-31 10:31 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Thomas Gleixner, LKML
In-Reply-To: <1143728884.26540.31.camel@localhost.localdomain>
* Steven Rostedt <rostedt@goodmis.org> wrote:
> Hi Ingo,
>
> The lock in check_monotonic_clock must be a raw spinlock since it is
> called from the hrtimer_interrupt.
thanks, applied.
Ingo
^ permalink raw reply
* Re: [e1000 debug] KERNEL: assertion (!sk_forward_alloc) failed...
From: Herbert Xu @ 2006-03-31 10:39 UTC (permalink / raw)
To: Boris B. Zhmurov
Cc: David S. Miller, jesse.brandeburg, nipsy, jrlundgren, cat,
djani22, yoseph.basri, mykleb, olel, michal, chris, netdev,
jesse.brandeburg, E1000-devel, Andi Kleen, Jeff Garzik
In-Reply-To: <442D0186.8090705@kernelpanic.ru>
[-- Attachment #1: Type: text/plain, Size: 890 bytes --]
On Fri, Mar 31, 2006 at 02:16:38PM +0400, Boris B. Zhmurov wrote:
>
> And xdelta tells, that e1000.ko was modified :)
Thanks for checking again.
Anyway, it didn't take long to find another bug in the same area.
I'm afraid this driver does seem to be full of them :)
It sets last_tx_tso in between computing the number of descriptors and
calling e1000_tx_map. This is bad because e1000_tx_map gets the wrong
value for last_tx_tso and therefore may corrupt memory for every TSO
packet when the ring is almost full.
This bug exists on UP as well as SMP.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Please try this in conjunction with the previous patch.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[-- Attachment #2: e1000-tso.patch --]
[-- Type: text/plain, Size: 645 bytes --]
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 49cd096..38aeff9 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -2891,7 +2891,6 @@
}
if (likely(tso)) {
- tx_ring->last_tx_tso = 1;
tx_flags |= E1000_TX_FLAGS_TSO;
} else if (likely(e1000_tx_csum(adapter, tx_ring, skb)))
tx_flags |= E1000_TX_FLAGS_CSUM;
@@ -2905,6 +2904,8 @@
e1000_tx_queue(adapter, tx_ring, tx_flags,
e1000_tx_map(adapter, tx_ring, skb, first,
max_per_txd, nr_frags, mss));
+
+ tx_ring->last_tx_tso = tso;
netdev->trans_start = jiffies;
^ permalink raw reply related
* Re: Hotplug and udev - a question
From: Chris Smith @ 2006-03-31 10:41 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <ada605fb0603310036s68fdb8d0x3fc6d73d135ffd7e@mail.gmail.com>
>>>>> "John" = John Que <qwejohn@gmail.com> writes:
John> Hello, I saw that in the last versions of udev, hotplug is
John> deprecated. Configuring of adding devices is done through
John> udev rules. Can anybody say in a few sentences why was this
John> change done? What are the advantages of conifguring with
John> udev rules over using hotplug ?
John> Best Regards, John
John,
Greg KH wrote an article that summarizes things nicely about a year ago:
http://lwn.net/Articles/123932/
Beating a drum from another post of mine that hasn't seen much
response, I hope that the documentation for building a bootable
kernel with all this udev goodness catches up. It's rather
mysterious at the moment.
Best,
Chris
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* moving board support from arch/ppc/ to arch/powerpc
From: Zang Roy-r61911 @ 2006-03-31 10:44 UTC (permalink / raw)
To: paulus; +Cc: linux-kernel
Hi,
I am moving mpc7448 hpc2 support from arch/ppc to arch/powerpc and plan to summit it to open source tree future. Is there any good suggestion or reference?
Thanks a lot!
Roy
^ permalink raw reply
* Re: [e1000 debug] KERNEL: assertion (!sk_forward_alloc) failed...
From: David S. Miller @ 2006-03-31 10:45 UTC (permalink / raw)
To: herbert
Cc: bb, jesse.brandeburg, nipsy, jrlundgren, cat, djani22,
yoseph.basri, mykleb, olel, michal, chris, netdev,
jesse.brandeburg, E1000-devel, ak, jgarzik
In-Reply-To: <20060331103956.GA12181@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 31 Mar 2006 21:39:56 +1100
> Anyway, it didn't take long to find another bug in the same area.
> I'm afraid this driver does seem to be full of them :)
Indeed.
Thanks for picking through this some more Herbert. I hope we got it
this time.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: Midi name string in mpu401_uart not unique
From: Alan Horstmann @ 2006-03-31 10:45 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
In-Reply-To: <s5hu09evs9b.wl%tiwai@suse.de>
On Friday 31 March 2006 11:10, you wrote:
> At Fri, 31 Mar 2006 11:02:37 +0100,
>
> Alan Horstmann wrote:
> > [1 <text/plain; iso-8859-1 (7bit)>]
> >
> > On Thursday 30 March 2006 18:53, you wrote:
> > > At Thu, 30 Mar 2006 18:45:23 +0100,
> > >
> > > Alan Horstmann wrote:
> > > > On Thursday 30 March 2006 12:04, you wrote:
> > > > > Instead of adding a new argument to snd_mpu401_uart_new, the caller
> > > > > can overwrite the string after creating the instace.
> > > > >
> > > > > snd_mpu401_uart_new(card, device, type, ..., &rmidi);
> > > > > snprintf(rmidi->name, sizeof(rmidi->name),
> > > > > "MIDI Name As I Like %d", card->number);
> > > > >
> > > > > Then the change would be less intrusive.
> > > > >
> > > > > Or am I missing something else?
> > > >
> > > > Sounds a lot simpler -just involving the driver only; I will try this
> > > > later. In the mpu-names.diff midi names were added to
> > > > snd_ice1712_card_info to be used in the name string. Is that still a
> > > > reasonable thing to do, or is there a better place, given that the
> > > > different sub-vendors might have different requirements?
> > >
> > > That addition looks OK to me. What I don't want is to change the
> > > existing API if there is a simple solution.
> > >
> > > > Bearing in mind Clemens' comments, is there any value in improving
> > > > the name given by mpu401_uart_new when using ->shortname, as in the
> > > > diff, by adding card and device numbers?
> > >
> > > Maybe the order of "CARD DEVICE" like "DMX6fire WaveTable" is better?
> > > Just a matter of taste, though...
> >
> > Would it be acceptable to add card, device to ->shortname in mpu401_uart
> > as attached:
> >
> > mpu401_uart.c-add-to-shortname.patch
> >
> > Add card and device numbers to portnames generated from ->shortnames by
> > snd_mpu401_uart_new.
> >
> > Signed-off-by: Alan Horstmann <gineera@aspect135.co.uk>
>
> Thanks for the patch. But I don't want to change that part at all.
> It may break other stuff what you've not tested.
>
> Just change the ice1712 stuff, instead.
O.K. That is fine. I understand you have to think of the 'larger picture'.
The question of the order of the parts of the name is similar to date formats
-yy-mm-dd or dd-mm-yy or other. I would think that convention in driver
names goes for CARD DEVICE suggesting DMX6fire WaveTable as you mentioned,
but usability is improved if the detail comes first, where it is less likely
to be truncated. If I offer a patch for ice1712, which would you prefer?
Regards Alan
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: pcm parameters, digital output ...
From: Jaroslav Kysela @ 2006-03-31 10:47 UTC (permalink / raw)
To: Johannes Berg; +Cc: alsa-devel, Takashi Iwai
In-Reply-To: <1143731165.4617.0.camel@localhost>
On Thu, 30 Mar 2006, Johannes Berg wrote:
> On Thu, 2006-03-30 at 16:51 +0200, Jaroslav Kysela wrote:
>
> > The mask is R/O variable and the bit definitions are different for
> > consumer and pro modes, so the driver can describe exactly which bits are
> > supported for these two different modes.
>
> Yes, I know, I just don't see why there are different modes. If the chip
> has different modes, shouldn't the driver be able to switch between them
> based on the consumer bit in the actual iec958 values it gets from
> userspace?
It's information for user space applications. The driver, of course,
ignores the extra bits, but the application should be able to determine
which bits are really send physically over IEC958 interface. Some Cirrus
Logic chips supports only limited iec958 channel status bits and these
bits are even different for pro and consumer modes.
> > AC97 code is probably not a good example. The "shift" to specific PCM
> > device is not implemented there. Look to snd_ice1712_spdif_build_controls
> > in ice1712.c . This code is good.
>
> Hmm, ok. Did you read my earlier discussion about why I do *not* want a
> shift to a specific pcm device?
Note that controls might be changed (removed, added) at runtime, but it's
not preferred, because the logic for applications is more complicated.
At least alsa-lib must have configuration for your iec958 device which
correctly handles the iec958 channel status bits. And this configuration
will describe which controls should be used.
> > I'm not sure, if we need a new format when we have information from the
> > control elements, that the stream is not PCM encoded. But on other hand,
> > these formats can be used with some conversion layers in alsa-lib
> > for handling of these streams and prevent extra things like resampling,
> > volume processing etc.
>
> Aha, good point, I could use the iec958 bits to determine the mode. But
> that's out-of-band information, so it is not too nice to rely on it
> imho. And exactly like you say, resampling etc. cannot be done on
> compressed information.
>
> > Also, there is a possibility to use subformat value (which is not used
> > so far for S16_LE/BE formats) for the non-pcm stream specification.
>
> I'm not too familiar with these internals :)
>
> What I'm currently doing is defining for each codec what kind of
> transfer formats it supports, see
> http://johannes.sipsolutions.net/gitweb.cgi?p=snd-aoa.git;a=blob;h=e3ca7a269906ceb41b411afcad14c54f4a181588;hb=4e1bc0b35020b3b1cac87f60cb67671e2c9a801e;f=aoa/codecs/onyx/snd-aoa-codec-onyx.c#l430
>
> Then the generic framework cuts that down to whatever is usable() at the
> moment depending on the selection of the iec958 and analog mute mixer
> elements. Hence there you can see what I'd like to do with a new format
> (which I called SNDRV_PCM_FMTBIT_COMPRESSED_16BE for now).
Basically, I'm against to create these new formats, because the data
organization is exactly same as for standard PCM samples. All what we
require is to set a non-audio flag somewhere for the data stream.
I would create SNDRV_PCM_SUBFORMAT_NONAUDIO and add subformat
bitmask handling to struct snd_pcm_hardware. Also, note that applications
passing AC3 or other compressed streams should set this subformat. To
provide backward compatibility, we should create a hack for the iec958
device in alsa-lib configuration which sets this subformat value when
AES0 contains the non-audio bit. The mechanism for handling the extra
iec958 parameters would remain same - using the control interface.
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re[2]: Recommendations for supported 4-port SATA PCI card ?
From: Jim Klimov @ 2006-03-31 10:48 UTC (permalink / raw)
To: Mattias Wadenstein; +Cc: Mark Hahn, linux-raid
In-Reply-To: <Pine.LNX.4.62.0603310524060.7170@chaos.egr.duke.edu>
Hello Joshua,
JBL> That's exactly why I recommended them. 3w-xxxx has been in the kernel a
JBL> *long* time and is extremely stable. Sure, it's expensive for "just" a
JBL> SATA controller, but not for a solid one that doesn't fall over at random
JBL> times.
Just for my 2 cents: we have a number of different generations of
3Ware cards (IDE and SATA) in our campus network, mostly with Western
Digital drives.
It seems quite beneficial to use their Raid Edition series of drives
instead of desktop ones. Beside the longer warranty and perhaps better
manufacturing and better resistance to vibration, according to the WD
site, these drives also report errors (if any) quicker to a host
adapter. This results in errors being handled by RAID hardware
gracefully, instead of the whole drive being considered as timed out.
In practice, we had some fun months with a RAID5 set made of desktop
Caviars rebuilding once in a while for no apparent reason, with each
disk working well for a long time. And we had no such problem with
RE disks for over a year now.
Hope this helps some list readers make their choice, and please don't
consider this an advertisement of certain brands ;) If any other
manufaturer offers capabilities similar to WD RE (especially timeouts),
please take a better look if you consider a hardware RAID controller.
--
Best regards,
Jim Klimov mailto:klimov@2ka.mipt.ru
^ permalink raw reply
* Re: [e1000 debug] KERNEL: assertion (!sk_forward_alloc) failed...
From: Boris B. Zhmurov @ 2006-03-31 10:51 UTC (permalink / raw)
To: David S. Miller
Cc: herbert, jesse.brandeburg, nipsy, jrlundgren, cat, djani22,
yoseph.basri, mykleb, olel, michal, chris, netdev,
jesse.brandeburg, E1000-devel, ak, jgarzik
In-Reply-To: <20060331.024544.96296223.davem@davemloft.net>
Hello, David S. Miller.
On 31.03.2006 14:45 you said the following:
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Fri, 31 Mar 2006 21:39:56 +1100
>
>
>>Anyway, it didn't take long to find another bug in the same area.
>>I'm afraid this driver does seem to be full of them :)
>
>
> Indeed.
>
> Thanks for picking through this some more Herbert. I hope we got it
> this time.
Recompiling the kernel. I need about 2 hours to get the answer...
--
Boris B. Zhmurov
mailto: bb@kernelpanic.ru
"wget http://kernelpanic.ru/bb_public_key.pgp -O - | gpg --import"
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: [e1000 debug] KERNEL: assertion (!sk_forward_alloc) failed...
From: Mark Nipper @ 2006-03-31 10:51 UTC (permalink / raw)
To: David S. Miller
Cc: herbert, netdev, jesse.brandeburg, nipsy, jrlundgren, cat,
djani22, yoseph.basri, bb, mykleb, olel, michal, chris, netdev,
jesse.brandeburg, E1000-devel
In-Reply-To: <20060331.013540.95485284.davem@davemloft.net>
On 31 Mar 2006, David S. Miller wrote:
> He does not have TSO enabled, e1000 disables TSO when on a link speed
> slower than gigabit.
>
> You'll see something like the following in your logs:
>
> e1000: eth0: e1000_watchdog_task: 10/100 speed: disabling TSO
Um...
---
$ uname -a
Linux king 2.6.16.1 #1 SMP Thu Mar 30 06:11:33 CST 2006 i686 GNU/Linux
$ dmesg | grep -i task
e1000: eth1: e1000_watchdog_task: NIC Link is Up 100 Mbps Full Duplex
$ ethtool -k eth1
Offload parameters for eth1:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
---
I know for a fact the link is 100Mbps (other than the
output from the driver itself) and I have been bitten by the
assertion.
I've been running the first patch for about the last 24
hours and have not seen any assertions yet (although they don't
occur that frequently on this server). I'll be adding the
second, most recent patch in a bit and rebooting again.
Hopefully between the two of them, that will have fixed the
problem.
--
Mark Nipper e-contacts:
832 Tanglewood Drive nipsy@bitgnome.net
Bryan, Texas 77802-4013 http://nipsy.bitgnome.net/
(979)575-3193 AIM/Yahoo: texasnipsy ICQ: 66971617
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GG/IT d- s++:+ a- C++$ UBL++++$ P--->+++ L+++$ !E---
W++(--) N+ o K++ w(---) O++ M V(--) PS+++(+) PE(--)
Y+ PGP t+ 5 X R tv b+++@ DI+(++) D+ G e h r++ y+(**)
------END GEEK CODE BLOCK------
---begin random quote of the moment---
And if I close my mind in fear, please pry it open.
----end random quote of the moment----
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: [e1000 debug] KERNEL: assertion (!sk_forward_alloc) failed...
From: Herbert Xu @ 2006-03-31 10:52 UTC (permalink / raw)
To: Boris B. Zhmurov
Cc: davem, herbert, jesse.brandeburg, nipsy, jrlundgren, cat, djani22,
yoseph.basri, mykleb, olel, michal, chris, netdev,
jesse.brandeburg, E1000-devel, ak, jgarzik
In-Reply-To: <442D09A3.3020700@kernelpanic.ru>
Boris B. Zhmurov <bb@kernelpanic.ru> wrote:
>
> Recompiling the kernel. I need about 2 hours to get the answer...
BTW, if you kept the built tree it is possible to apply the patch and
then do a make which should compile just the e1000 driver.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: pcm parameters, digital output ...
From: Johannes Berg @ 2006-03-31 10:55 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: alsa-devel, Takashi Iwai
In-Reply-To: <Pine.LNX.4.61.0603311204150.9303@tm8103.perex-int.cz>
[-- Attachment #1: Type: text/plain, Size: 1983 bytes --]
On Fri, 2006-03-31 at 12:47 +0200, Jaroslav Kysela wrote:
> It's information for user space applications. The driver, of course,
> ignores the extra bits, but the application should be able to determine
> which bits are really send physically over IEC958 interface. Some Cirrus
> Logic chips supports only limited iec958 channel status bits and these
> bits are even different for pro and consumer modes.
Well there are 192 bits in either case so I don't see your point? If the
mask says that the consumer/pro mode bit cannot be set, then the meaning
is clear by asking the device once for the bits and seeing whether pro
is on or not, and if it is settable then the application knows which it
set or can also ask whether it is set or not.
I don't see what more information the app could get from having a pro
mask and a con mask. Or is there hardware that changes the allowed mask
with the setting of pro/con mode??
> Basically, I'm against to create these new formats, because the data
> organization is exactly same as for standard PCM samples. All what we
> require is to set a non-audio flag somewhere for the data stream.
Right. But it needs to be within the stream info, not out-of-band with
the iec control like you suggested.
> I would create SNDRV_PCM_SUBFORMAT_NONAUDIO and add subformat
> bitmask handling to struct snd_pcm_hardware. Also, note that applications
> passing AC3 or other compressed streams should set this subformat. To
> provide backward compatibility, we should create a hack for the iec958
> device in alsa-lib configuration which sets this subformat value when
> AES0 contains the non-audio bit. The mechanism for handling the extra
> iec958 parameters would remain same - using the control interface.
That makes sense. Essentially, I'm happy if I can use the same stream
and tell during prepare() if compressed audio is going to be sent or
not. That's pretty much all that matters to me.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: NTH
From: Stephan Scholz @ 2006-03-31 10:58 UTC (permalink / raw)
To: Pedro Drimel Neto; +Cc: netfilter
In-Reply-To: <000501c65420$333e10b0$2f00a8c0@TRINTASETE>
Yes, that should work. Simply increase the "every" number and add a new rule.
Example for 4 hosts:
iptables -t nat -A POSTROUTING -o eth0 -d "Server Master" -m nth --counter 7 --every 4 --packet 0 -j SNAT --to-source 10.0.0.2
iptables -t nat -A POSTROUTING -o eth0 -d "Server Master" -m nth --counter 7 --every 4 --packet 1 -j SNAT --to-source 10.0.0.3
iptables -t nat -A POSTROUTING -o eth0 -d "Server Master" -m nth --counter 7 --every 4 --packet 2 -j SNAT --to-source 10.0.0.4
iptables -t nat -A POSTROUTING -o eth0 -d "Server Master" -m nth --counter 7 --every 4 --packet 3 -j SNAT --to-source 10.0.0.5
Stephan
Pedro Drimel Neto wrote:
> Hi all,
>
> I'm using the nth module for each connection it change of IP.
> The scenario is:
> -------------- -------------
> | Server with | ------ > | Server |
> | NTH | | Master |
> -------------- -------------
> So, the users connect to "Server with NTH" and the .bashrc of the user
> has a ssh to "Server Master".
> On "Server with NTH" has an interface, eth0, with 2 logics, eth0:0 and
> eth0:1
> eth0: 10.0.0.2
> eth0:0 10.0.0.3
> eth0:1: 10.0.0.4
> Above are the rules on "Server with NTH"
> iptables -t nat -A POSTROUTING -o eth0 -d "Server Master" -m nth
> --counter 7 --every 3 --packet 0 -j SNAT --to-source 10.0.0.2
> iptables -t nat -A POSTROUTING -o eth0 -d "Server Master" -m nth
> --counter 7 --every 3 --packet 1 -j SNAT --to-source 10.0.0.3
> iptables -t nat -A POSTROUTING -o eth0 -d "Server Master" -m nth
> --counter 7 --every 3 --packet 2 -j SNAT --to-source 10.0.0.4
>
> So, at each connection to "Server Master" the IP is changed.
> As NTH support only packet 0, 1 and 2 and I need to more IPs to be
> changed, if I add more a interface does it work ?
> Thanks a lot.
>
> Regards.
>
--
Stephan Scholz
sscholz@astaro.com | Development
Astaro AG | www.astaro.com | Phone +49-721-25516-0
Fax +49-721-25516-200
Amalienbadstraße 36 / Bau 33a | 76227 Karlsruhe | Germany
- PC Magazine Best of the Year 2004/2005
- CRN Best of the Year 2005
- SC Magazine "Best Buy" & 5 star rating - October 2005, Best of the Year 2005
- Internet Professionell "Empfehlung der Redaktion" - November 2005
^ permalink raw reply
* Re: SCSI selection issue with aic7xxx_old driver
From: Arjan van de Ven @ 2006-03-31 10:59 UTC (permalink / raw)
To: Kevin K; +Cc: linux-scsi
In-Reply-To: <F6783F90-89ED-4D3C-9D42-8F97D91907E0@sbcglobal.net>
On Wed, 2006-03-29 at 11:51 -0600, Kevin K wrote:
> I'm in the process up converting from RHEL 2.1 to RHEL 4, and have
> encountered an issue with the aic7xxx_old driver (5.2.6, as provided
> with the RH 2.4.9-34 kernel, and with 2.6.15.5 kernel).
>
> The SCSI card is an Adaptec 2940U card.
>
> Namely, an old SCSI device isn't being seen very often. Maybe 1 in
> 10 times loading the module. Under the 2.4.18 kernel, it was always
> seen using this driver except in the case of hardware/cabling issues.
>
> With the same hardware and OS, but using the new driver (aic7xxx),
> the hardware is consistently seen.
well... sounds you have a solution right there... ;)
the _old driver isn't really actively maintained anymore since... a long
time. At least the "new" one has been getting maintenance
^ permalink raw reply
* Re: [PATCH] splice exports
From: Arjan van de Ven @ 2006-03-31 11:01 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Andrew Morton, Linus Torvalds, axboe, linux-kernel
In-Reply-To: <20060331040613.GA23511@havoc.gtf.org>
On Thu, 2006-03-30 at 23:06 -0500, Jeff Garzik wrote:
> Woe be unto he who builds their filesystems as modules.
since splice support is highly linux specific and new.. shouldn't these
be _GPL exports?
^ permalink raw reply
* [PATCH] ata_piix: fix ich6/m_map_db
From: Tejun Heo @ 2006-03-31 11:01 UTC (permalink / raw)
To: Jeff Garzik, linux-ide
MAP tables of ich6 and ich6m are wrong. Depending on port usage,
ata_piix may fail to initialize attached devices.
Signed-off-by: Tejun Heo <htejun@gmail.com>
---
Jeff, this one is critical. I compiled all port allocation tables
correctly on my notebook, yet I succeeded to screw up. Dang. Sorry
about the trouble.
ata_piix.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: work/drivers/scsi/ata_piix.c
===================================================================
--- work.orig/drivers/scsi/ata_piix.c 2006-03-31 19:50:49.000000000 +0900
+++ work/drivers/scsi/ata_piix.c 2006-03-31 19:54:09.000000000 +0900
@@ -301,7 +301,7 @@ static struct piix_map_db ich6_map_db =
.mask = 0x3,
.map = {
/* PM PS SM SS MAP */
- { P0, P1, P2, P3 }, /* 00b */
+ { P0, P2, P1, P3 }, /* 00b */
{ IDE, IDE, P1, P3 }, /* 01b */
{ P0, P2, IDE, IDE }, /* 10b */
{ RV, RV, RV, RV },
@@ -312,7 +312,7 @@ static struct piix_map_db ich6m_map_db =
.mask = 0x3,
.map = {
/* PM PS SM SS MAP */
- { P0, P1, P2, P3 }, /* 00b */
+ { P0, P2, RV, RV }, /* 00b */
{ RV, RV, RV, RV },
{ P0, P2, IDE, IDE }, /* 10b */
{ RV, RV, RV, RV },
^ permalink raw reply
* Re: [e1000 debug] KERNEL: assertion (!sk_forward_alloc) failed...
From: Boris B. Zhmurov @ 2006-03-31 11:02 UTC (permalink / raw)
To: Herbert Xu
Cc: davem, jesse.brandeburg, nipsy, jrlundgren, cat, djani22,
yoseph.basri, mykleb, olel, michal, chris, netdev,
jesse.brandeburg, E1000-devel, ak, jgarzik
In-Reply-To: <E1FPHFJ-0003Fq-00@gondolin.me.apana.org.au>
Hello, Herbert Xu.
On 31.03.2006 14:52 you said the following:
> BTW, if you kept the built tree it is possible to apply the patch and
> then do a make which should compile just the e1000 driver.
>
> Cheers,
Thank's for the tip, actually I knew that :) First of, I've already
applied some other new patches from bk-commits-head. Not for the e1000
driver. And second - I didn't keep the tree, rpmbuild cleaned it up :)
That's why I'm recompiling entire kernel.
--
Boris B. Zhmurov
mailto: bb@kernelpanic.ru
"wget http://kernelpanic.ru/bb_public_key.pgp -O - | gpg --import"
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: [PATCH] splice exports
From: Jens Axboe @ 2006-03-31 11:02 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Jeff Garzik, Andrew Morton, Linus Torvalds, linux-kernel
In-Reply-To: <1143802879.3053.3.camel@laptopd505.fenrus.org>
On Fri, Mar 31 2006, Arjan van de Ven wrote:
> On Thu, 2006-03-30 at 23:06 -0500, Jeff Garzik wrote:
> > Woe be unto he who builds their filesystems as modules.
>
>
> since splice support is highly linux specific and new.. shouldn't these
> be _GPL exports?
Yes they should, I'll add that to the current splice tree.
--
Jens Axboe
^ permalink raw reply
* Re: Float numbers in module programming
From: Peter Williams @ 2006-03-31 11:05 UTC (permalink / raw)
To: Olivier Galibert, linux-kernel
In-Reply-To: <20060331075758.GB93977@dspnet.fr.eu.org>
Olivier Galibert wrote:
> On Thu, Mar 30, 2006 at 01:46:20PM -0500, linux-os (Dick Johnson) wrote:
>> Yeah. The correct word was irrational, which is its definition. The
>> point was that one can do a lot of very accurate work on real numbers
>> without using the FP unit and the decimal system.
>
> As long as you don't use sin/cos (oops, no 3D, no polar coordinates,
> no FFT), sqrt (oops no lenghts), pi (oops no non-polygonal surfaces)
> or ln/exp (oops, a lot of things are gone there).
>
> Working with rationals is not that realistic nowadays except in things
> like mathematica, maple and friends. Fixed-point though is still very
> realistics, it's just a different precision/scale tradeoff than fp,
> and one you control.
Fixed point is a special case of rational i.e. with a fixed denominator.
Peter
--
Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.