* [ALSA - driver 0001857]: regression in snd-cs4281 in recent 2.6.16-rcX kernels
From: bugtrack @ 2006-04-07 11:11 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1857>
======================================================================
Reported By: hoffmajs
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 1857
Category: PCI - cs4281
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution: Ubuntu (Dapper)
Kernel Version: 2.6.16-rc4
======================================================================
Date Submitted: 02-19-2006 06:11 CET
Last Modified: 04-07-2006 13:11 CEST
======================================================================
Summary: regression in snd-cs4281 in recent 2.6.16-rcX
kernels
Description:
In the recent 2.6.16-rc kernels snd-cs4281 broke for me.
(I think since 2.6.16-rc2, but Im not sure atm. In 2.6.15 the card works
fine.)
# > modprobe snd-cs4281
ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [LNKC] -> GSI 5 (level, low)
-> IRQ 5
never read ISV3 and ISV4 from AC'97
ACPI: PCI interrupt for device 0000:00:08.0 disabled
CS4281: probe of 0000:00:08.0 failed with error -5
and no soundcard is found.
If you need more info or want me to test something, please say so.
kind regards,
Jens
======================================================================
----------------------------------------------------------------------
julienbras - 04-05-06 10:33
----------------------------------------------------------------------
same problem on a debian sid, IBM Thinkpad X20.
The switch from 2.6.15 to 2.6.16 broke the sound
LSPCI output:
julien@x20:~$ sudo lspci -vs 00:0b
0000:00:0b.0 Multimedia audio controller: Cirrus Logic Crystal CS4281 PCI
Audio (rev 01)
Subsystem: IBM: Unknown device 0183
Flags: medium devsel, IRQ 11
Memory at f4010000 (32-bit, non-prefetchable) [size=4K]
Memory at f4000000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [40] Power Management version 2
DMESG output:
ACPI: PCI Interrupt 0000:00:0b.0[A] -> Link [LNKA] -> GSI 11 (level, low)
-> IRQ 11
never read ISV3 and ISV4 from AC'97
ACPI: PCI interrupt for device 0000:00:0b.0 disabled
CS4281: probe of 0000:00:0b.0 failed with error -5
----------------------------------------------------------------------
Mo6eB - 04-07-06 13:11
----------------------------------------------------------------------
Also happens here.
Debian unstable, custom-compiled kernel, as well as the precompiled kernel
in the Debian repository don't work.
Fujitsu/Siemens Lifebook C-4345
lspci -vs 00:08
0000:00:08.0 Multimedia audio controller: Cirrus Logic Crystal CS4281 PCI
Audio (rev 01)
Subsystem: Fujitsu Limited. Crystal CS4281 PCI Audio
Flags: medium devsel, IRQ 5
Memory at fc010000 (32-bit, non-prefetchable) [size=4K]
Memory at fc000000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [40] Power Management version 2
dmesg on a kernel, compiled with support for ACPI:
ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [LNKC] -> GSI 5 (level, low)
-> IRQ 5
ALSA sound/pci/cs4281.c:1577: never read ISV3 and ISV4 from AC'97
ACPI: PCI interrupt for device 0000:00:08.0 disabled
CS4281: probe of 0000:00:08.0 failed with error -5
dmesg on a kernel, compiled without support for ACPI:
PCI: Found IRQ 5 for device 0000:00:08.0
ALSA sound/pci/cs4281.c:1577: never read ISV3 and ISV4 from AC'97
CS4281: probe of 0000:00:08.0 failed with error -5
It doesn't seem like ACPI is the problem. The second kernel was compiled
with no support whatsoever for power management. If you need me to try
some specific configuration, do say so.
Issue History
Date Modified Username Field Change
======================================================================
02-19-06 06:11 hoffmajs New Issue
02-19-06 06:11 hoffmajs Distribution => Ubuntu (Dapper)
02-19-06 06:11 hoffmajs Kernel Version => 2.6.16-rc4
03-02-06 16:05 tiwai Note Added: 0008319
04-05-06 10:33 julienbras Note Added: 0009119
04-07-06 13:11 Mo6eB Note Added: 0009138
======================================================================
-------------------------------------------------------
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: RT task scheduling
From: Bill Huey @ 2006-04-07 11:14 UTC (permalink / raw)
To: Ingo Molnar
Cc: Darren Hart, linux-kernel, Thomas Gleixner, Stultz, John,
Peter Williams, Siddha, Suresh B, Nick Piggin, Bill Huey (hui)
In-Reply-To: <20060407105141.GA9972@elte.hu>
On Fri, Apr 07, 2006 at 12:51:41PM +0200, Ingo Molnar wrote:
> no, i'm discussing precisely the point you raised:
Oh boy.
> >>> You should consider for a moment to allow for the binding of a
> >>> thread to a CPU to determine the behavior of a SCHED_FIFO class task
> >>> instead of creating a new run category. [...]
>
> with the observation that 1) binding is already possible [so your
> suggestion is apparently knocking on open doors] 2) binding is a
> separate mechanism (not adequate for all workloads) and it is thus
> orthogonal to what i'm trying to achieve with the "RT overload" stuff.
> Really simple and straightforward observations i think.
This is going to take some time to get the terminology right. It's
late now and I'll have to continue this tomorrow.
First thing's first, SCHED_FIFO_GLOBAL for what you want in the main
line is the same thing as SCHED_FIFO in -rt, right ?
bill
^ permalink raw reply
* Re: noirqdebug_setup() in arch/i386/kernel/setup-xen.c
From: Keir Fraser @ 2006-04-07 11:16 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel
In-Reply-To: <443657E3.76F0.0078.0@novell.com>
On 7 Apr 2006, at 11:15, Jan Beulich wrote:
> Then, once we are able to figure the interrupt problems we currently
> have, this should probably be re-enabled
> temporarily and for *all* architectures, but be replaced by proper
> logic (i.e. Xen informing the domain e.g. by means of
> a flag passed with the injected IRQ that it should expect the
> interrupt to not getting handled; Xen should then also
> expect some notification back from the domain that the IRQ was
> handled, so it can combine this from all involved domains
> and still report and act on problems similar to the way Linux does).
That would be better, yes. :-)
-- Keir
^ permalink raw reply
* Re: Network accessibility problem
From: chuck gelm @ 2006-04-07 11:18 UTC (permalink / raw)
To: gerardo juarez-mondragon; +Cc: linux-admin
In-Reply-To: <0AE15BC76B45A2544A679DA133285E53@gjuarezmondragon.metacrawler.com>
gerardo juarez-mondragon wrote:
>I have a Fedora Core 2 server running in a
>network behind a firewall. I need access to ports
>22 and 80 from outside but the firewall
>administration is not under my control. I have
>requested this access to be opened and the
>administrator says it is already open, yet I
>still cannot access it from outside.
>
>I have run a few tests and this is what I found:
>
>(Filtering tables are flushed with iptables -F,
>on the server, prior to the tests)
>
>I can ping to/from it from/to any place, whether
>it is inside or outside the office.
>
>I can ssh to it from any place *inside*, but not
> from outside. A ssh -v from a computer outside
>succeeds up to the "entering event loop" message
>(which means it has presumably connected but the
>dialog does not proceed beyond this point).
>Viceversa, attempting a ssh session past the
>firewall results in an instantaneous 'Connection
>refused' message. The same connection from
>another computer succeeds, proving a ssh server
>was indeed running at the other end.
>
>telneting to port 80 produces this result:
>
>Trying 207.284.xxx.yyy...
>Connected to 207.248.xxx.yyy.
>Escape character is '^]'.
>
>when attempted from the (outside) ip authorized
>to access the computer. Any other ip just gets to
>the 'Trying...' line. This is correct and what
>should be happening, yet a browser reports
>'request sent' and proceeds no further when
>pointed to the address. (The Apache installation
>index page should be displayed).
>
>The administrator argues that some 'service'
>within my server is blocking packets, but I don't
>know that SSH can be configured to restrict
>access to specific ip segments. It can restrict
>access to *accounts*. Nor that there is such a
>service, except the firewall, whose tables I have
>already flushed.
>
>Am I missing something? What other tests do you
>suggest?
>
>Thanks,
>Gerardo
>
>
Dear Gerardo:
You mention only trying one port (ssh:22) from the 'outside'
and that the ssh attempt failed.
You did not mention that the 'Fedora Core 2 server" (FC2S)
has a routeable IP address. What ports of the FC2S are
reachable from the outside?
HTH, Chuck
^ permalink raw reply
* [U-Boot-Users] AMD 29LV160DB wrong ID
From: Hurricane555 @ 2006-04-07 11:27 UTC (permalink / raw)
To: u-boot
In-Reply-To: <3721580.post@talk.nabble.com>
I?m a litte bit confused!
I want to use the CFI_flash.c for my Flash, but I don?t know, what I do
wrong!?
At the moment I wrote this into my board.h:
#define CFG_FLASH_CFI_AMD_RESET
#define CONFIG_AMD_AM160LV
#define PHYS_FLASH_SIZE 0x00200000 /* 2 MB */
#define CFG_MAX_FLASH_SECT (35) /* max number of sectors on one chip */
#define CFG_MAX_FLASH_BANKS 1 /* Max # of flash banks */
#define CFG_ENV_ADDR (CFG_FLASH_BASE + 0x0F0000) /* addr of environment*/
#undef CFG_FLASH_CHECKSUM
#define CFG_FLASH_ERASE_TOUT 1024000 /* Flash Erase Timeout (ms) */
#define CFG_FLASH_WRITE_TOUT 500 /* Flash Write Timeout (ms) */
#define CFG_FLASH_CFI_DRIVER
#define CFG_FLASH_CFI
#define CFG_FLASH_EMPTY_INFO
#define CFG_ENV_IS_IN_FLASH 1
#define ENV_IS_EMBEDDED
#define CFG_ENV_OFFSET 0x8000 /* Offset of the Environment Sector
*/
#define CFG_ENV_SIZE 0x4000 /* Size of the Environment Sector
*/
is anything wrong? is anthing to be added?
my portwidth of my chip is 16bit but my buswidth is 32bit!
Please help!
--
View this message in context: http://www.nabble.com/AMD-29LV160DB-wrong-ID-t1385577.html#a3801893
Sent from the Uboot - Users forum at Nabble.com.
^ permalink raw reply
* [PATCH IP{,6}TABLES 0/4] fix loading icmpv6 module and minor changes
From: Yasuyuki KOZAKAI @ 2006-04-07 11:30 UTC (permalink / raw)
To: netfilter-devel; +Cc: laforge, kaber
Hi,
One patch fixes unusable icmpv6 because ip6tables doesn't try to load
libip6t_icmpv6.so. Others are minor fixes/cleanup in ip{,6}tables.
If no objection/miss, I'll commit them next weekend.
Regards,
-- Yasuyuki Kozakai
^ permalink raw reply
* [PATCH 1/4] fix loading shared library of ICMPv6 match
From: Yasuyuki KOZAKAI @ 2006-04-07 11:31 UTC (permalink / raw)
To: netfilter-devel; +Cc: laforge, kaber
In-Reply-To: <200603290725.k2T7PRIa020651@toshiba.co.jp>
[-- Attachment #1: Type: Text/Plain, Size: 732 bytes --]
From: Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp>
Date: Wed, 29 Mar 2006 16:25:27 +0900 (JST)
> From: "Daniel De Graaf" <danieldegraaf@gmail.com>
> Date: Sun, 26 Mar 2006 22:19:27 -0600
>
> > libip6t_icmpv6.c registers a match called "icmp6", which means that
> > ip6tables -vL and ip6tables-save cannot output the match correctly.
>
> There are 2 solutions.
>
> 1. just rename libip6t_icmpv6.c to libip6t_icmp6.c. This can
> conform names of internal structure, library and kernel module.
> 2. apply attached patch to fix find_match() so that ip6tables can
> load libip6t_icmpv6.so.
>
> I like 1 but I'm not sure we can do it. Anyone knows any historical
> problem about it ?
No problem ? OK, then I take 1.
[-- Attachment #2: 01-load-icmpv6.patch --]
[-- Type: Text/Plain, Size: 17209 bytes --]
[IP6TABLES] fix loading shared library of ICMPv6 match
The current ip6tables tries to load libip6t_icmp6.so when user types
'ip6tables -p icmpv6 ...' or 'ip6tables ... -m icmpv6' ...', and it fails.
This patch renames libip6t_icmpv6.c to libip6t_icmp6.c so that ip6tables
can load it. Now kernel module and user library has same name 'icmp6'.
It can reduce confusion about name mismatch. That's why I renamed it
instead of reverting change in find_match() which brought this bug.
This patch keeps compatibiity and we can use '-p icmpv6', '-p ipv6-icmpv6',
'-m icmpv6', '-m ipv6-icmpv6', and '-m icmp6', as ever.
---
commit f7eed26853dda6a51d70221f5c9ef0fac60f73a7
tree b064a28c63406f4ec54762731ad32a7a68234ae7
parent c94b52d4b6fff1bfc2da3e192b39e0f45cd12750
author Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Thu, 06 Apr 2006 22:18:27 +0900
committer Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Thu, 06 Apr 2006 22:18:27 +0900
extensions/Makefile | 2
extensions/libip6t_icmp6.c | 272 +++++++++++++++++++++++++++++++++++++++++
extensions/libip6t_icmp6.man | 14 ++
extensions/libip6t_icmpv6.c | 272 -----------------------------------------
extensions/libip6t_icmpv6.man | 14 --
5 files changed, 287 insertions(+), 287 deletions(-)
diff --git a/extensions/Makefile b/extensions/Makefile
index 7164e1d..af051f8 100644
--- a/extensions/Makefile
+++ b/extensions/Makefile
@@ -6,7 +6,7 @@
# package (HW)
#
PF_EXT_SLIB:=ah addrtype comment connlimit connmark conntrack dscp ecn esp hashlimit helper icmp iprange length limit mac mark multiport owner physdev pkttype policy realm rpc sctp standard state tcp tcpmss tos ttl udp unclean CLASSIFY CONNMARK DNAT DSCP ECN LOG MARK MASQUERADE MIRROR NETMAP NFQUEUE NOTRACK REDIRECT REJECT SAME SNAT TARPIT TCPMSS TOS TRACE TTL ULOG
-PF6_EXT_SLIB:=connmark eui64 hl icmpv6 length limit mac mark multiport owner physdev policy standard state tcp udp CONNMARK HL LOG NFQUEUE MARK TRACE
+PF6_EXT_SLIB:=connmark eui64 hl icmp6 length limit mac mark multiport owner physdev policy standard state tcp udp CONNMARK HL LOG NFQUEUE MARK TRACE
# Optionals
PF_EXT_SLIB_OPTS:=$(foreach T,$(wildcard extensions/.*-test),$(shell KERNEL_DIR=$(KERNEL_DIR) $(T)))
diff --git a/extensions/libip6t_icmp6.c b/extensions/libip6t_icmp6.c
new file mode 100644
index 0000000..a29bb38
--- /dev/null
+++ b/extensions/libip6t_icmp6.c
@@ -0,0 +1,272 @@
+/* Shared library add-on to iptables to add ICMP support. */
+#include <stdio.h>
+#include <netdb.h>
+#include <string.h>
+#include <stdlib.h>
+#include <getopt.h>
+#include <ip6tables.h>
+#include <linux/netfilter_ipv6/ip6_tables.h>
+
+struct icmpv6_names {
+ const char *name;
+ u_int8_t type;
+ u_int8_t code_min, code_max;
+};
+
+static const struct icmpv6_names icmpv6_codes[] = {
+ { "destination-unreachable", 1, 0, 0xFF },
+ { "no-route", 1, 0, 0 },
+ { "communication-prohibited", 1, 1, 1 },
+ { "address-unreachable", 1, 3, 3 },
+ { "port-unreachable", 1, 4, 4 },
+
+ { "packet-too-big", 2, 0, 0xFF },
+
+ { "time-exceeded", 3, 0, 0xFF },
+ /* Alias */ { "ttl-exceeded", 3, 0, 0xFF },
+ { "ttl-zero-during-transit", 3, 0, 0 },
+ { "ttl-zero-during-reassembly", 3, 1, 1 },
+
+ { "parameter-problem", 4, 0, 0xFF },
+ { "bad-header", 4, 0, 0 },
+ { "unknown-header-type", 4, 1, 1 },
+ { "unknown-option", 4, 2, 2 },
+
+ { "echo-request", 128, 0, 0xFF },
+ /* Alias */ { "ping", 128, 0, 0xFF },
+
+ { "echo-reply", 129, 0, 0xFF },
+ /* Alias */ { "pong", 129, 0, 0xFF },
+
+ { "router-solicitation", 133, 0, 0xFF },
+
+ { "router-advertisement", 134, 0, 0xFF },
+
+ { "neighbour-solicitation", 135, 0, 0xFF },
+ /* Alias */ { "neighbor-solicitation", 135, 0, 0xFF },
+
+ { "neighbour-advertisement", 136, 0, 0xFF },
+ /* Alias */ { "neighbor-advertisement", 136, 0, 0xFF },
+
+ { "redirect", 137, 0, 0xFF },
+
+};
+
+static void
+print_icmpv6types()
+{
+ unsigned int i;
+ printf("Valid ICMPv6 Types:");
+
+ for (i = 0; i < sizeof(icmpv6_codes)/sizeof(struct icmpv6_names); i++) {
+ if (i && icmpv6_codes[i].type == icmpv6_codes[i-1].type) {
+ if (icmpv6_codes[i].code_min == icmpv6_codes[i-1].code_min
+ && (icmpv6_codes[i].code_max
+ == icmpv6_codes[i-1].code_max))
+ printf(" (%s)", icmpv6_codes[i].name);
+ else
+ printf("\n %s", icmpv6_codes[i].name);
+ }
+ else
+ printf("\n%s", icmpv6_codes[i].name);
+ }
+ printf("\n");
+}
+
+/* Function which prints out usage message. */
+static void
+help(void)
+{
+ printf(
+"ICMPv6 v%s options:\n"
+" --icmpv6-type [!] typename match icmpv6 type\n"
+" (or numeric type or type/code)\n"
+"\n", IPTABLES_VERSION);
+ print_icmpv6types();
+}
+
+static struct option opts[] = {
+ { "icmpv6-type", 1, 0, '1' },
+ {0}
+};
+
+static void
+parse_icmpv6(const char *icmpv6type, u_int8_t *type, u_int8_t code[])
+{
+ unsigned int limit = sizeof(icmpv6_codes)/sizeof(struct icmpv6_names);
+ unsigned int match = limit;
+ unsigned int i;
+
+ for (i = 0; i < limit; i++) {
+ if (strncasecmp(icmpv6_codes[i].name, icmpv6type, strlen(icmpv6type))
+ == 0) {
+ if (match != limit)
+ exit_error(PARAMETER_PROBLEM,
+ "Ambiguous ICMPv6 type `%s':"
+ " `%s' or `%s'?",
+ icmpv6type,
+ icmpv6_codes[match].name,
+ icmpv6_codes[i].name);
+ match = i;
+ }
+ }
+
+ if (match != limit) {
+ *type = icmpv6_codes[match].type;
+ code[0] = icmpv6_codes[match].code_min;
+ code[1] = icmpv6_codes[match].code_max;
+ } else {
+ char *slash;
+ char buffer[strlen(icmpv6type) + 1];
+ unsigned int number;
+
+ strcpy(buffer, icmpv6type);
+ slash = strchr(buffer, '/');
+
+ if (slash)
+ *slash = '\0';
+
+ if (string_to_number(buffer, 0, 255, &number) == -1)
+ exit_error(PARAMETER_PROBLEM,
+ "Invalid ICMPv6 type `%s'\n", buffer);
+ *type = number;
+ if (slash) {
+ if (string_to_number(slash+1, 0, 255, &number) == -1)
+ exit_error(PARAMETER_PROBLEM,
+ "Invalid ICMPv6 code `%s'\n",
+ slash+1);
+ code[0] = code[1] = number;
+ } else {
+ code[0] = 0;
+ code[1] = 0xFF;
+ }
+ }
+}
+
+/* Initialize the match. */
+static void
+init(struct ip6t_entry_match *m, unsigned int *nfcache)
+{
+ struct ip6t_icmp *icmpv6info = (struct ip6t_icmp *)m->data;
+
+ icmpv6info->code[1] = 0xFF;
+}
+
+/* Function which parses command options; returns true if it
+ ate an option */
+static int
+parse(int c, char **argv, int invert, unsigned int *flags,
+ const struct ip6t_entry *entry,
+ unsigned int *nfcache,
+ struct ip6t_entry_match **match)
+{
+ struct ip6t_icmp *icmpv6info = (struct ip6t_icmp *)(*match)->data;
+
+ switch (c) {
+ case '1':
+ check_inverse(optarg, &invert, &optind, 0);
+ parse_icmpv6(argv[optind-1], &icmpv6info->type,
+ icmpv6info->code);
+ if (invert)
+ icmpv6info->invflags |= IP6T_ICMP_INV;
+ break;
+
+ default:
+ return 0;
+ }
+
+ return 1;
+}
+
+static void print_icmpv6type(u_int8_t type,
+ u_int8_t code_min, u_int8_t code_max,
+ int invert,
+ int numeric)
+{
+ if (!numeric) {
+ unsigned int i;
+
+ for (i = 0;
+ i < sizeof(icmpv6_codes)/sizeof(struct icmpv6_names);
+ i++) {
+ if (icmpv6_codes[i].type == type
+ && icmpv6_codes[i].code_min == code_min
+ && icmpv6_codes[i].code_max == code_max)
+ break;
+ }
+
+ if (i != sizeof(icmpv6_codes)/sizeof(struct icmpv6_names)) {
+ printf("%s%s ",
+ invert ? "!" : "",
+ icmpv6_codes[i].name);
+ return;
+ }
+ }
+
+ if (invert)
+ printf("!");
+
+ printf("type %u", type);
+ if (code_min == 0 && code_max == 0xFF)
+ printf(" ");
+ else if (code_min == code_max)
+ printf(" code %u ", code_min);
+ else
+ printf(" codes %u-%u ", code_min, code_max);
+}
+
+/* Prints out the union ipt_matchinfo. */
+static void
+print(const struct ip6t_ip6 *ip,
+ const struct ip6t_entry_match *match,
+ int numeric)
+{
+ const struct ip6t_icmp *icmpv6 = (struct ip6t_icmp *)match->data;
+
+ printf("ipv6-icmp ");
+ print_icmpv6type(icmpv6->type, icmpv6->code[0], icmpv6->code[1],
+ icmpv6->invflags & IP6T_ICMP_INV,
+ numeric);
+
+ if (icmpv6->invflags & ~IP6T_ICMP_INV)
+ printf("Unknown invflags: 0x%X ",
+ icmpv6->invflags & ~IP6T_ICMP_INV);
+}
+
+/* Saves the match in parsable form to stdout. */
+static void save(const struct ip6t_ip6 *ip, const struct ip6t_entry_match *match)
+{
+ const struct ip6t_icmp *icmpv6 = (struct ip6t_icmp *)match->data;
+
+ if (icmpv6->invflags & IP6T_ICMP_INV)
+ printf("! ");
+
+ printf("--icmpv6-type %u", icmpv6->type);
+ if (icmpv6->code[0] != 0 || icmpv6->code[1] != 0xFF)
+ printf("/%u", icmpv6->code[0]);
+ printf(" ");
+}
+
+/* Final check; we don't care. */
+static void final_check(unsigned int flags)
+{
+}
+
+static struct ip6tables_match icmpv6 = {
+ .name = "icmp6",
+ .version = IPTABLES_VERSION,
+ .size = IP6T_ALIGN(sizeof(struct ip6t_icmp)),
+ .userspacesize = IP6T_ALIGN(sizeof(struct ip6t_icmp)),
+ .help = &help,
+ .init = &init,
+ .parse = &parse,
+ .final_check = &final_check,
+ .print = &print,
+ .save = &save,
+ .extra_opts = opts,
+};
+
+void _init(void)
+{
+ register_match6(&icmpv6);
+}
diff --git a/extensions/libip6t_icmp6.man b/extensions/libip6t_icmp6.man
new file mode 100644
index 0000000..2047180
--- /dev/null
+++ b/extensions/libip6t_icmp6.man
@@ -0,0 +1,14 @@
+This extension is loaded if `--protocol ipv6-icmp' or `--protocol icmpv6' is
+specified. It provides the following option:
+.TP
+.BR "--icmpv6-type " "[!] \fItype\fP[/\fIcode\fP]|\fItypename\fP"
+This allows specification of the ICMPv6 type, which can be a numeric
+ICMPv6
+.IR type ,
+.IR type
+and
+.IR code ,
+or one of the ICMPv6 type names shown by the command
+.nf
+ ip6tables -p ipv6-icmp -h
+.fi
diff --git a/extensions/libip6t_icmpv6.c b/extensions/libip6t_icmpv6.c
deleted file mode 100644
index a29bb38..0000000
--- a/extensions/libip6t_icmpv6.c
+++ /dev/null
@@ -1,272 +0,0 @@
-/* Shared library add-on to iptables to add ICMP support. */
-#include <stdio.h>
-#include <netdb.h>
-#include <string.h>
-#include <stdlib.h>
-#include <getopt.h>
-#include <ip6tables.h>
-#include <linux/netfilter_ipv6/ip6_tables.h>
-
-struct icmpv6_names {
- const char *name;
- u_int8_t type;
- u_int8_t code_min, code_max;
-};
-
-static const struct icmpv6_names icmpv6_codes[] = {
- { "destination-unreachable", 1, 0, 0xFF },
- { "no-route", 1, 0, 0 },
- { "communication-prohibited", 1, 1, 1 },
- { "address-unreachable", 1, 3, 3 },
- { "port-unreachable", 1, 4, 4 },
-
- { "packet-too-big", 2, 0, 0xFF },
-
- { "time-exceeded", 3, 0, 0xFF },
- /* Alias */ { "ttl-exceeded", 3, 0, 0xFF },
- { "ttl-zero-during-transit", 3, 0, 0 },
- { "ttl-zero-during-reassembly", 3, 1, 1 },
-
- { "parameter-problem", 4, 0, 0xFF },
- { "bad-header", 4, 0, 0 },
- { "unknown-header-type", 4, 1, 1 },
- { "unknown-option", 4, 2, 2 },
-
- { "echo-request", 128, 0, 0xFF },
- /* Alias */ { "ping", 128, 0, 0xFF },
-
- { "echo-reply", 129, 0, 0xFF },
- /* Alias */ { "pong", 129, 0, 0xFF },
-
- { "router-solicitation", 133, 0, 0xFF },
-
- { "router-advertisement", 134, 0, 0xFF },
-
- { "neighbour-solicitation", 135, 0, 0xFF },
- /* Alias */ { "neighbor-solicitation", 135, 0, 0xFF },
-
- { "neighbour-advertisement", 136, 0, 0xFF },
- /* Alias */ { "neighbor-advertisement", 136, 0, 0xFF },
-
- { "redirect", 137, 0, 0xFF },
-
-};
-
-static void
-print_icmpv6types()
-{
- unsigned int i;
- printf("Valid ICMPv6 Types:");
-
- for (i = 0; i < sizeof(icmpv6_codes)/sizeof(struct icmpv6_names); i++) {
- if (i && icmpv6_codes[i].type == icmpv6_codes[i-1].type) {
- if (icmpv6_codes[i].code_min == icmpv6_codes[i-1].code_min
- && (icmpv6_codes[i].code_max
- == icmpv6_codes[i-1].code_max))
- printf(" (%s)", icmpv6_codes[i].name);
- else
- printf("\n %s", icmpv6_codes[i].name);
- }
- else
- printf("\n%s", icmpv6_codes[i].name);
- }
- printf("\n");
-}
-
-/* Function which prints out usage message. */
-static void
-help(void)
-{
- printf(
-"ICMPv6 v%s options:\n"
-" --icmpv6-type [!] typename match icmpv6 type\n"
-" (or numeric type or type/code)\n"
-"\n", IPTABLES_VERSION);
- print_icmpv6types();
-}
-
-static struct option opts[] = {
- { "icmpv6-type", 1, 0, '1' },
- {0}
-};
-
-static void
-parse_icmpv6(const char *icmpv6type, u_int8_t *type, u_int8_t code[])
-{
- unsigned int limit = sizeof(icmpv6_codes)/sizeof(struct icmpv6_names);
- unsigned int match = limit;
- unsigned int i;
-
- for (i = 0; i < limit; i++) {
- if (strncasecmp(icmpv6_codes[i].name, icmpv6type, strlen(icmpv6type))
- == 0) {
- if (match != limit)
- exit_error(PARAMETER_PROBLEM,
- "Ambiguous ICMPv6 type `%s':"
- " `%s' or `%s'?",
- icmpv6type,
- icmpv6_codes[match].name,
- icmpv6_codes[i].name);
- match = i;
- }
- }
-
- if (match != limit) {
- *type = icmpv6_codes[match].type;
- code[0] = icmpv6_codes[match].code_min;
- code[1] = icmpv6_codes[match].code_max;
- } else {
- char *slash;
- char buffer[strlen(icmpv6type) + 1];
- unsigned int number;
-
- strcpy(buffer, icmpv6type);
- slash = strchr(buffer, '/');
-
- if (slash)
- *slash = '\0';
-
- if (string_to_number(buffer, 0, 255, &number) == -1)
- exit_error(PARAMETER_PROBLEM,
- "Invalid ICMPv6 type `%s'\n", buffer);
- *type = number;
- if (slash) {
- if (string_to_number(slash+1, 0, 255, &number) == -1)
- exit_error(PARAMETER_PROBLEM,
- "Invalid ICMPv6 code `%s'\n",
- slash+1);
- code[0] = code[1] = number;
- } else {
- code[0] = 0;
- code[1] = 0xFF;
- }
- }
-}
-
-/* Initialize the match. */
-static void
-init(struct ip6t_entry_match *m, unsigned int *nfcache)
-{
- struct ip6t_icmp *icmpv6info = (struct ip6t_icmp *)m->data;
-
- icmpv6info->code[1] = 0xFF;
-}
-
-/* Function which parses command options; returns true if it
- ate an option */
-static int
-parse(int c, char **argv, int invert, unsigned int *flags,
- const struct ip6t_entry *entry,
- unsigned int *nfcache,
- struct ip6t_entry_match **match)
-{
- struct ip6t_icmp *icmpv6info = (struct ip6t_icmp *)(*match)->data;
-
- switch (c) {
- case '1':
- check_inverse(optarg, &invert, &optind, 0);
- parse_icmpv6(argv[optind-1], &icmpv6info->type,
- icmpv6info->code);
- if (invert)
- icmpv6info->invflags |= IP6T_ICMP_INV;
- break;
-
- default:
- return 0;
- }
-
- return 1;
-}
-
-static void print_icmpv6type(u_int8_t type,
- u_int8_t code_min, u_int8_t code_max,
- int invert,
- int numeric)
-{
- if (!numeric) {
- unsigned int i;
-
- for (i = 0;
- i < sizeof(icmpv6_codes)/sizeof(struct icmpv6_names);
- i++) {
- if (icmpv6_codes[i].type == type
- && icmpv6_codes[i].code_min == code_min
- && icmpv6_codes[i].code_max == code_max)
- break;
- }
-
- if (i != sizeof(icmpv6_codes)/sizeof(struct icmpv6_names)) {
- printf("%s%s ",
- invert ? "!" : "",
- icmpv6_codes[i].name);
- return;
- }
- }
-
- if (invert)
- printf("!");
-
- printf("type %u", type);
- if (code_min == 0 && code_max == 0xFF)
- printf(" ");
- else if (code_min == code_max)
- printf(" code %u ", code_min);
- else
- printf(" codes %u-%u ", code_min, code_max);
-}
-
-/* Prints out the union ipt_matchinfo. */
-static void
-print(const struct ip6t_ip6 *ip,
- const struct ip6t_entry_match *match,
- int numeric)
-{
- const struct ip6t_icmp *icmpv6 = (struct ip6t_icmp *)match->data;
-
- printf("ipv6-icmp ");
- print_icmpv6type(icmpv6->type, icmpv6->code[0], icmpv6->code[1],
- icmpv6->invflags & IP6T_ICMP_INV,
- numeric);
-
- if (icmpv6->invflags & ~IP6T_ICMP_INV)
- printf("Unknown invflags: 0x%X ",
- icmpv6->invflags & ~IP6T_ICMP_INV);
-}
-
-/* Saves the match in parsable form to stdout. */
-static void save(const struct ip6t_ip6 *ip, const struct ip6t_entry_match *match)
-{
- const struct ip6t_icmp *icmpv6 = (struct ip6t_icmp *)match->data;
-
- if (icmpv6->invflags & IP6T_ICMP_INV)
- printf("! ");
-
- printf("--icmpv6-type %u", icmpv6->type);
- if (icmpv6->code[0] != 0 || icmpv6->code[1] != 0xFF)
- printf("/%u", icmpv6->code[0]);
- printf(" ");
-}
-
-/* Final check; we don't care. */
-static void final_check(unsigned int flags)
-{
-}
-
-static struct ip6tables_match icmpv6 = {
- .name = "icmp6",
- .version = IPTABLES_VERSION,
- .size = IP6T_ALIGN(sizeof(struct ip6t_icmp)),
- .userspacesize = IP6T_ALIGN(sizeof(struct ip6t_icmp)),
- .help = &help,
- .init = &init,
- .parse = &parse,
- .final_check = &final_check,
- .print = &print,
- .save = &save,
- .extra_opts = opts,
-};
-
-void _init(void)
-{
- register_match6(&icmpv6);
-}
diff --git a/extensions/libip6t_icmpv6.man b/extensions/libip6t_icmpv6.man
deleted file mode 100644
index 2047180..0000000
--- a/extensions/libip6t_icmpv6.man
+++ /dev/null
@@ -1,14 +0,0 @@
-This extension is loaded if `--protocol ipv6-icmp' or `--protocol icmpv6' is
-specified. It provides the following option:
-.TP
-.BR "--icmpv6-type " "[!] \fItype\fP[/\fIcode\fP]|\fItypename\fP"
-This allows specification of the ICMPv6 type, which can be a numeric
-ICMPv6
-.IR type ,
-.IR type
-and
-.IR code ,
-or one of the ICMPv6 type names shown by the command
-.nf
- ip6tables -p ipv6-icmp -h
-.fi
^ permalink raw reply related
* [PATCH 2/4] kill manually comparing protocol name with "ipv6-icmp"
From: Yasuyuki KOZAKAI @ 2006-04-07 11:31 UTC (permalink / raw)
To: netfilter-devel; +Cc: laforge, kaber
[-- Attachment #1: 02-proto-icmpv6.patch --]
[-- Type: Text/Plain, Size: 1549 bytes --]
[IP6TABLES] kill manually comparing protocol name with "ipv6-icmp"
This adds "ipv6-icmp" to chain_protos[] and kill manually comparing
the argument of '-p' with it.
chain_protos[] has the "icmpv6" with the same protocol number, but it's
OK because proto_to_name() returns the firstly matched entry "icmpv6"
as ever.
---
commit 62607c174a8c1cc7a4f18e7537be75a1d5a87944
tree f1c65a0db8d249e19a4c35b46d95e7d8f1eaf628
parent f7eed26853dda6a51d70221f5c9ef0fac60f73a7
author Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Thu, 06 Apr 2006 22:34:56 +0900
committer Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Thu, 06 Apr 2006 22:34:56 +0900
ip6tables.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/ip6tables.c b/ip6tables.c
index dcf7d36..1279888 100644
--- a/ip6tables.c
+++ b/ip6tables.c
@@ -222,6 +222,7 @@ static const struct pprot chain_protos[]
{ "tcp", IPPROTO_TCP },
{ "udp", IPPROTO_UDP },
{ "icmpv6", IPPROTO_ICMPV6 },
+ { "ipv6-icmp", IPPROTO_ICMPV6 },
{ "esp", IPPROTO_ESP },
{ "ah", IPPROTO_AH },
};
@@ -1748,7 +1749,6 @@ int do_command6(int argc, char *argv[],
char *protocol = NULL;
const char *modprobe = NULL;
int proto_used = 0;
- char icmp6p[] = "icmpv6";
memset(&fw, 0, sizeof(fw));
@@ -1917,8 +1917,6 @@ int do_command6(int argc, char *argv[],
*protocol = tolower(*protocol);
protocol = argv[optind-1];
- if ( strcmp(protocol,"ipv6-icmp") == 0)
- protocol = icmp6p;
fw.ipv6.proto = parse_protocol(protocol);
fw.ipv6.flags |= IP6T_F_PROTO;
^ permalink raw reply related
* [PATCH 3/4] check invalid esp spi range
From: Yasuyuki KOZAKAI @ 2006-04-07 11:31 UTC (permalink / raw)
To: netfilter-devel; +Cc: laforge, kaber
[-- Attachment #1: 03-esp.patch --]
[-- Type: Text/Plain, Size: 1410 bytes --]
[IPTABLES,IP6TABLES]: check invalid esp spi range
---
commit c2faea0a63833f5b8c65542c36a24ee1fb53207b
tree 3c49018aafea3725abbf6b1519bbc252b5374b7b
parent c94b52d4b6fff1bfc2da3e192b39e0f45cd12750
author Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Thu, 06 Apr 2006 20:21:50 +0900
committer Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Thu, 06 Apr 2006 20:21:50 +0900
extensions/libip6t_esp.c | 3 +++
extensions/libipt_esp.c | 3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/extensions/libip6t_esp.c b/extensions/libip6t_esp.c
index 29e865d..886e09b 100644
--- a/extensions/libip6t_esp.c
+++ b/extensions/libip6t_esp.c
@@ -61,6 +61,9 @@ parse_esp_spis(const char *spistring, u_
spis[0] = buffer[0] ? parse_esp_spi(buffer) : 0;
spis[1] = cp[0] ? parse_esp_spi(cp) : 0xFFFFFFFF;
+ if (spis[0] > spis[1])
+ exit_error(PARAMETER_PROBLEM,
+ "Invalid ESP spi range: %s", spistring);
}
free(buffer);
}
diff --git a/extensions/libipt_esp.c b/extensions/libipt_esp.c
index 4abfba3..21e912b 100644
--- a/extensions/libipt_esp.c
+++ b/extensions/libipt_esp.c
@@ -62,6 +62,9 @@ parse_esp_spis(const char *spistring, u_
spis[0] = buffer[0] ? parse_esp_spi(buffer) : 0;
spis[1] = cp[0] ? parse_esp_spi(cp) : 0xFFFFFFFF;
+ if (spis[0] > spis[1])
+ exit_error(PARAMETER_PROBLEM,
+ "Invalid ESP spi range: %s", spistring);
}
free(buffer);
}
^ permalink raw reply related
* Re: RT task scheduling
From: Ingo Molnar @ 2006-04-07 11:29 UTC (permalink / raw)
To: Bill Huey
Cc: Darren Hart, linux-kernel, Thomas Gleixner, Stultz, John,
Peter Williams, Siddha, Suresh B, Nick Piggin
In-Reply-To: <20060407111444.GA12458@gnuppy.monkey.org>
* Bill Huey <billh@gnuppy.monkey.org> wrote:
> > >>> You should consider for a moment to allow for the binding of a
> > >>> thread to a CPU to determine the behavior of a SCHED_FIFO class task
> > >>> instead of creating a new run category. [...]
> >
> > with the observation that 1) binding is already possible [so your
> > suggestion is apparently knocking on open doors] 2) binding is a
> > separate mechanism (not adequate for all workloads) and it is thus
> > orthogonal to what i'm trying to achieve with the "RT overload" stuff.
> > Really simple and straightforward observations i think.
> First thing's first, SCHED_FIFO_GLOBAL for what you want in the main
> line is the same thing as SCHED_FIFO in -rt, right ?
yes.
Ingo
^ permalink raw reply
* [lm-sensors] [PATCH] hwmon: Add w83791d support
From: Jean Delvare @ 2006-04-07 11:33 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <5bfe43f80604041606n5a99ecbcg234ae8532b016b6c@mail.gmail.com>
Hi Yuan,
> > It is making sure the two temp sensors are enabled while preserving
> > the reserved bits (the w83792 driver is doing this also). If you reset
> > the chip the HW takes care of this. Guess I can remove the code and
> > assume the BIOS is doing the right thing when reset=0...
>
> I dont like this "reset" or "init", i would like to drop this parameter
> and do nothing about temp2,temp3 configuration.
> because we may lose MB specific configuration if we reset the chip,
> What's your opinion?
I share your worries about possibly losing the configuration set by the
BIOS. I believe that the BIOS should always configure the hardware
monitoring chips properly (because they know exactly what features the
board has) and even if most BIOSes unfortunately don't do that, we must
respect the ones that do.
Now, having a module parameter to control what kind of reset and/or
initialization is done is fine by me, as long as the default is to
preserve the BIOS settings as much as possible.
So, enabling temp2 and temp3 should indeed not be done unconditionally.
Charles, you might want to have three degrees of initialization: only
start monitoring, or enable temp2 and temp3 beforehand, or reset the
chip beforehand. This can be done using two boolean module parameters
(reset and init), or just one parameter (init) with three values, at
your option.
--
Jean Delvare
^ permalink raw reply
* [PATCH 4/4] fix the path to detect esp/connbytes support in kernel
From: Yasuyuki KOZAKAI @ 2006-04-07 11:34 UTC (permalink / raw)
To: netfilter-devel; +Cc: laforge, kaber
[-- Attachment #1: 04-test.patch --]
[-- Type: Text/Plain, Size: 1309 bytes --]
[IPTABLES,IP6TABLES]: fix the path to detect esp/connbytes support in kernel
The recent kernels don't have ipt_connbytes.c and ip6t_esp.c.
---
commit 12bc86c77dae9d0590c5ee021d9c00f2291bfe0b
tree 29a3b1b160d4784a2b264c348d1f781eedbb0ae5
parent c94b52d4b6fff1bfc2da3e192b39e0f45cd12750
author Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Thu, 06 Apr 2006 20:18:10 +0900
committer Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Thu, 06 Apr 2006 20:18:10 +0900
extensions/.connbytes-test | 2 +-
extensions/.esp-test6 | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/extensions/.connbytes-test b/extensions/.connbytes-test
index 350140f..61355d0 100755
--- a/extensions/.connbytes-test
+++ b/extensions/.connbytes-test
@@ -1,2 +1,2 @@
#! /bin/sh
-[ -f $KERNEL_DIR/net/ipv4/netfilter/ipt_connbytes.c ] && echo connbytes
+[ -f $KERNEL_DIR/include/linux/netfilter_ipv4/ipt_connbytes.h ] && echo connbytes
diff --git a/extensions/.esp-test6 b/extensions/.esp-test6
index ff63ca4..7ded945 100755
--- a/extensions/.esp-test6
+++ b/extensions/.esp-test6
@@ -1,2 +1,2 @@
#!/bin/sh
-[ -f $KERNEL_DIR/net/ipv6/netfilter/ip6t_esp.c -a -f $KERNEL_DIR/include/linux/netfilter_ipv6/ip6t_esp.h ] && echo esp
+[ -f $KERNEL_DIR/include/linux/netfilter_ipv6/ip6t_esp.h ] && echo esp
^ permalink raw reply related
* Re: [2.6 patch] remove the obsolete IDEPCI_FLAG_FORCE_PDC
From: Bartlomiej Zolnierkiewicz @ 2006-04-07 11:41 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Sergei Shtylylov, Alan Cox, linux-kernel, linux-ide
In-Reply-To: <20060407003101.GF7118@stusta.de>
On 4/7/06, Adrian Bunk <bunk@stusta.de> wrote:
> On Mon, Mar 27, 2006 at 04:40:20PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > On 3/27/06, Sergei Shtylylov <sshtylyov@ru.mvista.com> wrote:
> >...
> > > > .flags = IDEPCI_FLAG_FORCE_PDC,
> > >
> > > A late question: wasn't that IDEPCI_FLAG_FORCE_PDC flag there for the same
> > > purpose -- to bypass enablebits check? Wasn't it enough?
> >
> > It was for the same purpose but it wasn't enough,
> > now this flag can die...
>
> IOW, we want the patch below?
Yes. Could you please add my ACK and forward it to akpm?
> > Bartlomiej
>
> cu
> Adrian
>
>
> <-- snip -->
>
>
> This patch removes the obsolete IDEPCI_FLAG_FORCE_PDC.
>
> Noted by Sergei Shtylylov <sshtylyov@ru.mvista.com>
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> ---
>
> drivers/ide/pci/pdc202xx_old.c | 2 --
> drivers/ide/setup-pci.c | 13 -------------
> include/linux/ide.h | 1 -
> 3 files changed, 16 deletions(-)
>
> --- linux-2.6.17-rc1-mm1-full/include/linux/ide.h.old 2006-04-07 00:51:49.000000000 +0200
> +++ linux-2.6.17-rc1-mm1-full/include/linux/ide.h 2006-04-07 00:52:03.000000000 +0200
> @@ -1221,7 +1221,6 @@
> enum {
> /* Uses ISA control ports not PCI ones. */
> IDEPCI_FLAG_ISA_PORTS = (1 << 0),
> - IDEPCI_FLAG_FORCE_PDC = (1 << 1),
> };
>
> typedef struct ide_pci_device_s {
> --- linux-2.6.17-rc1-mm1-full/drivers/ide/pci/pdc202xx_old.c.old 2006-04-07 00:52:13.000000000 +0200
> +++ linux-2.6.17-rc1-mm1-full/drivers/ide/pci/pdc202xx_old.c 2006-04-07 00:52:19.000000000 +0200
> @@ -798,7 +798,6 @@
> .autodma = AUTODMA,
> .bootable = OFF_BOARD,
> .extra = 48,
> - .flags = IDEPCI_FLAG_FORCE_PDC,
> },{ /* 2 */
> .name = "PDC20263",
> .init_setup = init_setup_pdc202ata4,
> @@ -819,7 +818,6 @@
> .autodma = AUTODMA,
> .bootable = OFF_BOARD,
> .extra = 48,
> - .flags = IDEPCI_FLAG_FORCE_PDC,
> },{ /* 4 */
> .name = "PDC20267",
> .init_setup = init_setup_pdc202xx,
> --- linux-2.6.17-rc1-mm1-full/drivers/ide/setup-pci.c.old 2006-04-07 00:52:27.000000000 +0200
> +++ linux-2.6.17-rc1-mm1-full/drivers/ide/setup-pci.c 2006-04-07 00:54:28.000000000 +0200
> @@ -580,7 +580,6 @@
> int port;
> int at_least_one_hwif_enabled = 0;
> ide_hwif_t *hwif, *mate = NULL;
> - static int secondpdc = 0;
> u8 tmp;
>
> index->all = 0xf0f0;
> @@ -592,21 +591,9 @@
> for (port = 0; port <= 1; ++port) {
> ide_pci_enablebit_t *e = &(d->enablebits[port]);
>
> - /*
> - * If this is a Promise FakeRaid controller,
> - * the 2nd controller will be marked as
> - * disabled while it is actually there and enabled
> - * by the bios for raid purposes.
> - * Skip the normal "is it enabled" test for those.
> - */
> - if ((d->flags & IDEPCI_FLAG_FORCE_PDC) &&
> - (secondpdc++==1) && (port==1))
> - goto controller_ok;
> -
> if (e->reg && (pci_read_config_byte(dev, e->reg, &tmp) ||
> (tmp & e->mask) != e->val))
> continue; /* port not enabled */
> -controller_ok:
>
> if (d->channels <= port)
> break;
^ permalink raw reply
* Re: accessing mirrired lvm on shared storage
From: Chris Osicki @ 2006-04-07 11:46 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <44355BC9.4020608@mailing.kaufland-informationssysteme.com>
Matthias
I have currently four clusters which mirror shared storage. I've
always pay great attention not to have an array active on both
cluster nodes. I can imagine data corruption would happen soon or
late.
Unfortunately md lacks the ability to mark an array as
used/busy/you_name_it. Sometime ago I asked on this list for such an
enhancement (see thread with subject "Question: array locking,
possible"). Although I managed (with great help from few people on
this list) to attract Neil's attention, I couldn't fine enough
arguments to convince him to put this topic on hist TO-DO list.
Neil, you see the constantly growing number of potential users of this
feature? ;-)
Regards,
Chris
PS Matthias, just curious, you don't have FC failover, right?
On Thu, 06 Apr 2006 20:19:53 +0200
Matthias Eble <matthias.eble@mailing.kaufland-informationssysteme.com> wrote:
>
> Hi all,
>
> I've got an extended setup whith two Systems, each with two FC cards.
> Every card is connected to a seperate disk array (so one system accesses
> two arrays). The other node has access to the same two arrays (standby).
>
> The active server mirrors the data (4 LUNs) between the two arrays via
> md. On top is a LVM physical volume. The other system is meant to be
> booted but not acessing the VGs.
>
> My question is, if it is possible to let both systems set up the md
> mirror without corrupting the data? Is there any data written even when
> the VGs are not taken active? I think I remember that LVM refuses to
> activate volumegroups which are active on another system, right?
> This would save me from caring about IO fencing.
>
> thanks for your help in advance..
> matthias
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [lm-sensors] [PATCH] hwmon: Add w83791d support
From: Jean Delvare @ 2006-04-07 11:47 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <5bfe43f80604041606n5a99ecbcg234ae8532b016b6c@mail.gmail.com>
Hi Charles,
> Thanks for taking the time to look this over. I long ago learned the
> value of code reviews and got another reminder on this one :)
I'm doing my best with the little time I have now... I know there are
several drivers waiting for me to review them, but I just can't do
everything at once.
> > In a more general way, you may want to take a look at the recent
> > changes which were made to the w83792d driver, and see if they could
> > apply to your code too.
>
> I'll grab an older kernel tree and compare this file with a recent git
> tree. Are there more changes that are not yet in git20 that I should
> be aware of? Should I be comparing against a different tree (like the
> -mm tree) or is there a special lmsensor archive/tree?
Well you can use the web interface to git to get the history of the
w83792d driver:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=drivers/hwmon/w83792d.c
As for the pending patches, there's only one I am aware of, and I
already pointed you to it if I remember correctly:
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/i2c/hwmon-w83792d-quiet-on-misdetection.patch
> > + for (i = 0; i < 2; i++) {
> > + device_create_file(dev, &sda_beep_ctrl[i].dev_attr);
> > + }
> >
> > You could use ARRAY_SIZE(sda_beep_ctrl) instead of hardcoding 2. This
> > is easier to understand for the reader, and more robust to future
> > changes too. I'm not sure if this array really adds anything though.
>
> It seemed like the array structure "grouped" things a bit and provided
> some consistency given all the other "groups" were now arrays
> (voltage, fan, temp). I can go either way on this if you have a
> preference.
No strong preference, do it the way you want.
> > > + temp2_cfg = w83791d_read(client, W83791D_REG_TEMP2_CONFIG);
> > > + temp3_cfg = w83791d_read(client, W83791D_REG_TEMP3_CONFIG);
> > > + w83791d_write(client, W83791D_REG_TEMP2_CONFIG, temp2_cfg & 0xe6);
> > > + w83791d_write(client, W83791D_REG_TEMP3_CONFIG, temp3_cfg & 0xe6);
> >
> > What are these doing? This needs a comment. Also note that you could do
> > with a single temporary variable (or even without one.)
>
> It is making sure the two temp sensors are enabled while preserving
> the reserved bits (the w83792 driver is doing this also). If you reset
> the chip the HW takes care of this. Guess I can remove the code and
> assume the BIOS is doing the right thing when reset=0...
See my other post (answering to Yuan) for this.
> > * sensors-detect needs to be updated, as for now it points the W83791D
> > owners to the w83781d driver regardless of the kernel version. Patch
> > anyone?
>
> Yes, it detects the w83791d correctly and tells you to load the w83781d driver:
>
> Driver `w83781d' (should be inserted):
> Detects correctly:
> * Bus `SMBus I801 adapter at 0540'
> Busdriver `i2c-i801', I2C address 0x2c (and 0x48 0x49)
> Chip `Winbond W83791D' (confidence: 7)
>
> I haven't looked at that code/scripts, but I can update depending on
> how you want to handle it (check for 2.4 vs. 2.6 and output as
> appropriate?)
I haven't look in deep either, but I remember that we have a similar
case for one SiS SMBus driver: it's named i2c-sis645 on Linux 2.4 and
i2c-sis96x on Linux 2.6, and we have some code to pick the right driver
depending on the kernel version. So let's do it the same way for the
W83791D case and it should be fine.
Thanks,
--
Jean Delvare
^ permalink raw reply
* [PATCH] aic79xx: target hotplug fixes
From: Hannes Reinecke @ 2006-04-07 11:47 UTC (permalink / raw)
To: SCSI Mailing List
[-- Attachment #1: Type: text/plain, Size: 993 bytes --]
Hi all,
aic79xx has a _very_ peculiar handling for target hotplug. It detects
the target reset okay, but then decides to change the command on the fly
to TEST UNIT READY and tries to requeue the original command.
Nice idea, but if we can't send the TEST UNIT READY command we'll get
the sense code from that and not that one we'd have gotten from the
original command.
And of course the requeueing bit is stuffed, too, as the TUR command
will basically never requeued.
Especially harmful if the Midlayer does a rescanning, as the INQUIRY
command sent by the rescan should _never_ return a CHECK CONDITION
status as this is a violation of the SCSI spec.
This patch just strips out that peculiar handling and let the midlayer
deal with it. Works far better that way and again some code cleanup
achieved :-)
Please apply.
Cheers,
Hannes
--
Dr. Hannes Reinecke hare@suse.de
SuSE Linux Products GmbH S390 & zSeries
Maxfeldstraße 5 +49 911 74053 688
90409 Nürnberg http://www.suse.de
[-- Attachment #2: 0001-aic79xx-target-hotplug-fixes.txt --]
[-- Type: text/plain, Size: 4338 bytes --]
Subject: [PATCH] aic79xx: target hotplug fixes
When a target is added aic79xx tries to be overly clever: it changes
the command on the fly to TEST UNIT READY and tries to requeue the
original command. Sadly this breaks SCSI compability and of course
the midlayer is getting a bit confused by it.
So we're just removing that bit of code and let the midlayer deal with
it. It's clever enough by now. And the driver code is getting simpler.
Signed-off-by: Hannes Reinecke <hare@suse.de>
---
drivers/scsi/aic7xxx/aic79xx.h | 2 +
drivers/scsi/aic7xxx/aic79xx_core.c | 52 ++++++-----------------------------
2 files changed, 10 insertions(+), 44 deletions(-)
41b91d017439519c496ceb20ee877b8fedd2b61b
diff --git a/drivers/scsi/aic7xxx/aic79xx.h b/drivers/scsi/aic7xxx/aic79xx.h
index 1d11f7e..1c85db6 100644
--- a/drivers/scsi/aic7xxx/aic79xx.h
+++ b/drivers/scsi/aic7xxx/aic79xx.h
@@ -589,7 +589,7 @@ typedef enum {
SCB_PACKETIZED = 0x00800,
SCB_EXPECT_PPR_BUSFREE = 0x01000,
SCB_PKT_SENSE = 0x02000,
- SCB_CMDPHASE_ABORT = 0x04000,
+ SCB_EXTERNAL_RESET = 0x04000,/* Device was reset externally */
SCB_ON_COL_LIST = 0x08000,
SCB_SILENT = 0x10000 /*
* Be quiet about transmission type
diff --git a/drivers/scsi/aic7xxx/aic79xx_core.c b/drivers/scsi/aic7xxx/aic79xx_core.c
index 326a622..9ab0209 100644
--- a/drivers/scsi/aic7xxx/aic79xx_core.c
+++ b/drivers/scsi/aic7xxx/aic79xx_core.c
@@ -1054,12 +1054,10 @@ ahd_handle_seqint(struct ahd_softc *ahd,
* If a target takes us into the command phase
* assume that it has been externally reset and
* has thus lost our previous packetized negotiation
- * agreement. Since we have not sent an identify
- * message and may not have fully qualified the
- * connection, we change our command to TUR, assert
- * ATN and ABORT the task when we go to message in
- * phase. The OSM will see the REQUEUE_REQUEST
- * status and retry the command.
+ * agreement.
+ * Revert to async/narrow transfers until we
+ * can renegotiate with the device and notify
+ * the OSM about the reset.
*/
scbid = ahd_get_scbptr(ahd);
scb = ahd_lookup_scb(ahd, scbid);
@@ -1086,31 +1084,15 @@ ahd_handle_seqint(struct ahd_softc *ahd,
ahd_set_syncrate(ahd, &devinfo, /*period*/0,
/*offset*/0, /*ppr_options*/0,
AHD_TRANS_ACTIVE, /*paused*/TRUE);
- ahd_outb(ahd, SCB_CDB_STORE, 0);
- ahd_outb(ahd, SCB_CDB_STORE+1, 0);
- ahd_outb(ahd, SCB_CDB_STORE+2, 0);
- ahd_outb(ahd, SCB_CDB_STORE+3, 0);
- ahd_outb(ahd, SCB_CDB_STORE+4, 0);
- ahd_outb(ahd, SCB_CDB_STORE+5, 0);
- ahd_outb(ahd, SCB_CDB_LEN, 6);
- scb->hscb->control &= ~(TAG_ENB|SCB_TAG_TYPE);
- scb->hscb->control |= MK_MESSAGE;
- ahd_outb(ahd, SCB_CONTROL, scb->hscb->control);
- ahd_outb(ahd, MSG_OUT, HOST_MSG);
- ahd_outb(ahd, SAVED_SCSIID, scb->hscb->scsiid);
- /*
- * The lun is 0, regardless of the SCB's lun
- * as we have not sent an identify message.
- */
- ahd_outb(ahd, SAVED_LUN, 0);
- ahd_outb(ahd, SEQ_FLAGS, 0);
- ahd_assert_atn(ahd);
- scb->flags &= ~SCB_PACKETIZED;
- scb->flags |= SCB_ABORT|SCB_CMDPHASE_ABORT;
+ scb->flags |= SCB_EXTERNAL_RESET;
ahd_freeze_devq(ahd, scb);
ahd_set_transaction_status(scb, CAM_REQUEUE_REQ);
ahd_freeze_scb(scb);
+ /* Notify XPT */
+ ahd_send_async(ahd, devinfo.channel, devinfo.target,
+ CAM_LUN_WILDCARD, AC_SENT_BDR, NULL);
+
/*
* Allow the sequencer to continue with
* non-pack processing.
@@ -2207,22 +2189,6 @@ ahd_handle_nonpkt_busfree(struct ahd_sof
if (sent_msg == MSG_ABORT_TAG)
tag = SCB_GET_TAG(scb);
- if ((scb->flags & SCB_CMDPHASE_ABORT) != 0) {
- /*
- * This abort is in response to an
- * unexpected switch to command phase
- * for a packetized connection. Since
- * the identify message was never sent,
- * "saved lun" is 0. We really want to
- * abort only the SCB that encountered
- * this error, which could have a different
- * lun. The SCB will be retried so the OS
- * will see the UA after renegotiating to
- * packetized.
- */
- tag = SCB_GET_TAG(scb);
- saved_lun = scb->hscb->lun;
- }
found = ahd_abort_scbs(ahd, target, 'A', saved_lun,
tag, ROLE_INITIATOR,
CAM_REQ_ABORTED);
--
1.1.3
^ permalink raw reply related
* Re: [patch 1/3] mm: An enhancement of OVERCOMMIT_GUESS
From: Hideo AOKI @ 2006-04-07 11:49 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: akpm, linux-kernel, linux-mm
In-Reply-To: <20060406170851.1402c78d.kamezawa.hiroyu@jp.fujitsu.com>
[-- Attachment #1: Type: text/plain, Size: 1869 bytes --]
Hi Kamezawa-san,
Thank you for your quick response. And sorry for slow response.
KAMEZAWA Hiroyuki wrote:
> Hideo AOKI <haoki@redhat.com> wrote:
>
>>Since __vm_enough_memory() doesn't know zone and cpuset information,
>>we have to guess proper value of lowmem_reserve in each zone
>>like I did in calculate_totalreserve_pages() in my patch.
>>Do you think that we can do this calculation every time?
>>
>>If it is good enough, I'll make revised patch.
>>
>
> I just thought to show "how to calculate" in unified way is better.
I got it.
> Do you have a detailed comparison of test result with and without this patch ?
Yes. I have test logs and attach them to this e-mail.
The logs are verbose output of my test kernel module which I already
sent to lkml.
http://marc.theaimsgroup.com/?l=linux-kernel&m=114428121522349&w=2
Test machine was i386 4GB memory PC. I didn't use swap region.
Let me explain a few things about the log.
* 2.6.17-rc1-mm1
HIGH: <active 18220><inactive 12278><free 1419><sum 31917><present 622220>
NORMAL: <active 1618><inactive 2293><free 1397><sum 5308><present 225280>
The test module consumes free pages until the number of free pages
is less than pages_high.
<buf 3916><cache 31785><slab reclaim 1550><swap 0> <+ 1> <target 33336>
This line shows the status of memory just before the module calls
__vm_enough_memory(). Meaning of each item is below.
buf: bufferram
cache: page cache
slab reclaim: slab_reclaim_pages
swap: nr_swap_pages
+: margin
target: the number of pages to ask __vm_enough_memory()
Test MAY be <failed>.
This line shows __vm_enough_memory() returned success.
Please let me know if you have any questions and suggestions.
Regards,
Hideo Aoki
---
Hideo Aoki, Hitachi Computer Products (America) Inc.
[-- Attachment #2: log-2.6.17-rc1-mm1.txt --]
[-- Type: text/plain, Size: 2233 bytes --]
* 2.6.17-rc1-mm1
Apr 6 20:33:33 dhcp1 kernel: Test module was loaded. <mode 1>
Apr 6 20:33:33 dhcp1 kernel: init ...<3>done
Apr 6 20:33:33 dhcp1 kernel:
Apr 6 20:33:33 dhcp1 kernel: HIGH: <active 18238><inactive 12278><free 590698><sum 621214><present 622220>
Apr 6 20:33:34 dhcp1 kernel: HighMem <target 589272>, <3>
Apr 6 20:33:34 dhcp1 kernel: HIGH: <active 18220><inactive 12278><free 1512><sum 32010><present 622220>
Apr 6 20:33:34 dhcp1 kernel:
Apr 6 20:33:34 dhcp1 kernel: HIGH: <active 18220><inactive 12278><free 1512><sum 32010><present 622220>
Apr 6 20:33:34 dhcp1 kernel: HighMem <target 86>, <3>
Apr 6 20:33:34 dhcp1 kernel: HIGH: <active 18220><inactive 12278><free 1419><sum 31917><present 622220>
Apr 6 20:33:34 dhcp1 kernel: already satisfied
Apr 6 20:33:34 dhcp1 kernel:
Apr 6 20:33:34 dhcp1 kernel: NORMAL: <active 1618><inactive 2277><free 205532><sum 209427><present 225280>
Apr 6 20:33:34 dhcp1 kernel: Normal <target 204124>, <3>
Apr 6 20:33:34 dhcp1 kernel: NORMAL: <active 1618><inactive 2291><free 1490><sum 5399><present 225280>
Apr 6 20:33:34 dhcp1 kernel:
Apr 6 20:33:34 dhcp1 kernel: NORMAL: <active 1618><inactive 2293><free 1490><sum 5401><present 225280>
Apr 6 20:33:34 dhcp1 kernel: Normal <target 82>, <3>
Apr 6 20:33:34 dhcp1 kernel: NORMAL: <active 1618><inactive 2293><free 1428><sum 5339><present 225280>
Apr 6 20:33:34 dhcp1 kernel:
Apr 6 20:33:34 dhcp1 kernel: NORMAL: <active 1618><inactive 2293><free 1428><sum 5339><present 225280>
Apr 6 20:33:34 dhcp1 kernel: Normal <target 20>, <3>
Apr 6 20:33:34 dhcp1 kernel: NORMAL: <active 1618><inactive 2293><free 1397><sum 5308><present 225280>
Apr 6 20:33:34 dhcp1 kernel: already satisfied
Apr 6 20:33:34 dhcp1 kernel: concrete test ...
Apr 6 20:33:34 dhcp1 kernel: <buf 3916><cache 31785><slab reclaim 1550><swap 0> <+ 1> <target 33336>
Apr 6 20:33:34 dhcp1 kernel: Test MAY be <failed>.
Apr 6 20:33:34 dhcp1 kernel: allocation failed: out of vmalloc space - use
vmalloc=<size> to increase size.
Apr 6 20:33:35 dhcp1 kernel: allocation failed: out of vmalloc space - use
vmalloc=<size> to increase size.
Apr 6 20:33:35 dhcp1 kernel: Test SURELY was <FAILED>.
Apr 6 20:33:35 dhcp1 kernel: concrete test ...done.
[-- Attachment #3: log-2.6.17-rc1-mm1+patch.txt --]
[-- Type: text/plain, Size: 4053 bytes --]
* 2.6.17-rc1-mm1 + patches
Apr 6 20:56:36 dhcp1 kernel: Test module was loaded. <mode 1>
Apr 6 20:56:36 dhcp1 kernel: init ...<3>done
Apr 6 20:56:36 dhcp1 kernel:
Apr 6 20:56:36 dhcp1 kernel: HIGH: <active 17074><inactive 13427><free 590727><sum 621228><present 622220>
Apr 6 20:56:36 dhcp1 kernel: HighMem <target 589301>, <3>
Apr 6 20:56:36 dhcp1 kernel: HIGH: <active 17074><inactive 13427><free 1479><sum 31980><present 622220>
Apr 6 20:56:36 dhcp1 kernel:
Apr 6 20:56:36 dhcp1 kernel: HIGH: <active 17074><inactive 13427><free 1479><sum 31980><present 622220>
Apr 6 20:56:36 dhcp1 kernel: HighMem <target 53>, <3>
Apr 6 20:56:36 dhcp1 kernel: HIGH: <active 17074><inactive 13427><free 1417><sum 31918><present 622220>
Apr 6 20:56:36 dhcp1 kernel: already satisfied
Apr 6 20:56:36 dhcp1 kernel:
Apr 6 20:56:36 dhcp1 kernel: NORMAL: <active 1626><inactive 2248><free 205669><sum 209543><present 225280>
Apr 6 20:56:36 dhcp1 kernel: Normal <target 204261>, <3>
Apr 6 20:56:36 dhcp1 kernel: NORMAL: <active 1626><inactive 2262><free 1441><sum 5329><present 225280>
Apr 6 20:56:36 dhcp1 kernel:
Apr 6 20:56:36 dhcp1 kernel: NORMAL: <active 1626><inactive 2264><free 1441><sum 5331><present 225280>
Apr 6 20:56:36 dhcp1 kernel: Normal <target 33>, <3>
Apr 6 20:56:36 dhcp1 kernel: NORMAL: <active 1626><inactive 2264><free 1410><sum 5300><present 225280>
Apr 6 20:56:36 dhcp1 kernel:
Apr 6 20:56:36 dhcp1 kernel: NORMAL: <active 1626><inactive 2264><free 1410><sum 5300><present 225280>
Apr 6 20:56:36 dhcp1 kernel: Normal <target 2>, <3>
Apr 6 20:56:36 dhcp1 kernel: NORMAL: <active 1626><inactive 2265><free 1410><sum 5301><present 225280>
Apr 6 20:56:36 dhcp1 kernel:
Apr 6 20:56:36 dhcp1 kernel: NORMAL: <active 1626><inactive 2265><free 1410><sum 5301><present 225280>
Apr 6 20:56:36 dhcp1 kernel: Normal <target 2>, <3>
Apr 6 20:56:36 dhcp1 kernel: NORMAL: <active 1626><inactive 2265><free 1410><sum 5301><present 225280>
Apr 6 20:56:36 dhcp1 kernel:
Apr 6 20:56:36 dhcp1 kernel: NORMAL: <active 1626><inactive 2265><free 1410><sum 5301><present 225280>
Apr 6 20:56:36 dhcp1 kernel: Normal <target 2>, <3>
Apr 6 20:56:36 dhcp1 kernel: NORMAL: <active 1626><inactive 2265><free 1410><sum 5301><present 225280>
Apr 6 20:56:36 dhcp1 kernel:
Apr 6 20:56:36 dhcp1 kernel: NORMAL: <active 1626><inactive 2265><free 1410><sum 5301><present 225280>
Apr 6 20:56:36 dhcp1 kernel: Normal <target 2>, <3>
Apr 6 20:56:36 dhcp1 kernel: NORMAL: <active 1626><inactive 2265><free 1410><sum 5301><present 225280>
Apr 6 20:56:36 dhcp1 kernel:
Apr 6 20:56:36 dhcp1 kernel: NORMAL: <active 1626><inactive 2265><free 1410><sum 5301><present 225280>
Apr 6 20:56:36 dhcp1 kernel: Normal <target 2>, <3>
Apr 6 20:56:36 dhcp1 kernel: NORMAL: <active 1626><inactive 2265><free 1410><sum 5301><present 225280>
Apr 6 20:56:36 dhcp1 kernel:
Apr 6 20:56:36 dhcp1 kernel: NORMAL: <active 1626><inactive 2265><free 1410><sum 5301><present 225280>
Apr 6 20:56:36 dhcp1 kernel: Normal <target 2>, <3>
Apr 6 20:56:36 dhcp1 kernel: NORMAL: <active 1626><inactive 2265><free 1410><sum 5301><present 225280>
Apr 6 20:56:36 dhcp1 kernel:
Apr 6 20:56:36 dhcp1 kernel: NORMAL: <active 1626><inactive 2265><free 1410><sum 5301><present 225280>
Apr 6 20:56:36 dhcp1 kernel: Normal <target 2>, <3>
Apr 6 20:56:36 dhcp1 kernel: NORMAL: <active 1626><inactive 2265><free 1410><sum 5301><present 225280>
Apr 6 20:56:36 dhcp1 kernel:
Apr 6 20:56:36 dhcp1 kernel: NORMAL: <active 1626><inactive 2265><free 1410><sum 5301><present 225280>
Apr 6 20:56:36 dhcp1 kernel: Normal <target 2>, <3>
Apr 6 20:56:36 dhcp1 kernel: NORMAL: <active 1626><inactive 2265><free 1379><sum 5270><present 225280>
Apr 6 20:56:36 dhcp1 kernel: already satisfied
Apr 6 20:56:36 dhcp1 kernel: concrete test ...
Apr 6 20:56:36 dhcp1 kernel: <buf 3902><cache 31720><slab reclaim 1538><swap 0> <+ 1> <target 33259>
Apr 6 20:56:36 dhcp1 kernel: Test was <PASSED>.
Apr 6 20:56:36 dhcp1 kernel: concrete test ...done.
Apr 6 20:56:48 dhcp1 kernel: Unloading module ...
^ permalink raw reply
* RE: "xm top" broke in 3.0-testing
From: Ian Pratt @ 2006-04-07 11:51 UTC (permalink / raw)
To: Matt Ayres, xen-devel
Works for me.
Are you sure you've updated all the binaries in your install?
Ian
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Matt Ayres
> Sent: 07 April 2006 00:36
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] "xm top" broke in 3.0-testing
>
> Subject says about all..
>
> # xm top
> Failed to retrieve statistics from libxenstat
>
> xen_caps : xen-3.0-x86_32p
> platform_params : virt_start=0xf5800000
> xen_changeset : Thu Apr 6 18:34:32 2006 +0100
> 9595:32b22f5286be
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
^ permalink raw reply
* Re: Network accessibility problem
From: Andreas P. Koenzen @ 2006-04-07 11:54 UTC (permalink / raw)
To: gerardo juarez-mondragon; +Cc: linux-admin
In-Reply-To: <0AE15BC76B45A2544A679DA133285E53@gjuarezmondragon.metacrawler.com>
gerardo juarez-mondragon wrote:
> I have a Fedora Core 2 server running in a
> network behind a firewall. I need access to ports
> 22 and 80 from outside but the firewall
> administration is not under my control. I have
> requested this access to be opened and the
> administrator says it is already open, yet I
> still cannot access it from outside.
>
> I have run a few tests and this is what I found:
>
> (Filtering tables are flushed with iptables -F,
> on the server, prior to the tests)
>
> I can ping to/from it from/to any place, whether
> it is inside or outside the office.
>
> I can ssh to it from any place *inside*, but not
> from outside. A ssh -v from a computer outside
> succeeds up to the "entering event loop" message
> (which means it has presumably connected but the
> dialog does not proceed beyond this point).
> Viceversa, attempting a ssh session past the
> firewall results in an instantaneous 'Connection
> refused' message. The same connection from
> another computer succeeds, proving a ssh server
> was indeed running at the other end.
>
> telneting to port 80 produces this result:
>
> Trying 207.284.xxx.yyy...
> Connected to 207.248.xxx.yyy.
> Escape character is '^]'.
>
> when attempted from the (outside) ip authorized
> to access the computer. Any other ip just gets to
> the 'Trying...' line. This is correct and what
> should be happening, yet a browser reports
> 'request sent' and proceeds no further when
> pointed to the address. (The Apache installation
> index page should be displayed).
>
> The administrator argues that some 'service'
> within my server is blocking packets, but I don't
> know that SSH can be configured to restrict
> access to specific ip segments. It can restrict
> access to *accounts*. Nor that there is such a
> service, except the firewall, whose tables I have
> already flushed.
>
> Am I missing something? What other tests do you
> suggest?
>
> Thanks,
> Gerardo
>
>
>
>
> Searching for the best free email? Try MetaCrawler Mail, from the #1 metasearch service on the Web, http://www.metacrawler.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-admin" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
Hello Gerardo...
The problem that you are experience it's coming from the Servers'
Iptables Rules, you really should check with your server Admin. Maybe
the port 22 and 80 are block from connections coming from an IP outside
the range of your local network. If you can log into a the server from
within the network and not from outside it is probably a rule from
Iptables blocking outside connections.
Saludos
AKC
^ permalink raw reply
* Re: [PATCH] spufs: fix compile
From: Christoph Hellwig @ 2006-04-07 11:54 UTC (permalink / raw)
To: arndb; +Cc: linuxppc-dev
In-Reply-To: <20060406134810.GB8552@lst.de>
On Thu, Apr 06, 2006 at 03:48:10PM +0200, Christoph Hellwig wrote:
> The current tree isn't exctly sure about the arguments to
> alloc_spu_context, let it agree on the no-arguments version.
Please ignore all these patches, I had a messed up tree.
^ permalink raw reply
* Re: [Xenomai-core] Frozen timer IRQ
From: Jan Kiszka @ 2006-04-07 11:57 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai-core
In-Reply-To: <44354CC5.8080405@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 2749 bytes --]
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>
>>> Jan Kiszka wrote:
>>>
>>>> Philippe Gerum wrote:
>>>>
>>>>
>>>>> Jan Kiszka wrote:
>>>>>
>>>>>
>>>>>> Attached is an ipipe-freeze of the frozen system. It's taken at the
>>>>>> time
>>>>>> the main thread of the terminating application has successfully
>>>>>> rt_task_join'ed the last remaining RT-thread. I took 2000 trace
>>>>>> points
>>>>>> before and after that point and additionally instrumented
>>>>>> rthal_timer_program_shot() (special trace 0x01, the argument is the
>>>>>> delay). The interesting stuff happens around 600 us after the
>>>>>> freeze: it
>>>>>> seems the scheduled Linux timer arrives then but doesn't get much
>>>>>> attention beyond from ipipe.
>>>>>>
>>>>>> Any idea what to look for next? I have a "perfect" test system now,
>>>>>> though I still see no light at the end of the tunnel how to export
>>>>>> it to
>>>>>> other boxes.
>>>>>>
>>>>>> Enough for today.
>>>>>>
>>>>>> Jan
>>>>>>
>>>>>>
>>>>>> PS: This trace was taken over 2.6.15 to exclude any issues with
>>>>>> the new
>>>>>> 2.6.16. Both kernels show the same effect.
>>>>>>
>>>>>
>>>>> Does this patch make any difference?
>>>>>
>>>>> --- ipipe-root.c~ 2006-01-31 09:55:44.000000000 +0100
>>>>> +++ ipipe-root.c 2006-04-06 17:01:49.000000000 +0200
>>>>> @@ -328,9 +328,8 @@
>>>>> /* Only sync virtual IRQs here, so that we don't recurse
>>>>> indefinitely in case of an external interrupt flood. */
>>>>>
>>>>> - if ((ipipe_root_domain->cpudata[cpuid].
>>>>> - irq_pending_hi & IPIPE_IRQMASK_VIRT) != 0)
>>>>> - __ipipe_sync_stage(IPIPE_IRQMASK_VIRT);
>>>>> + if (ipipe_root_domain->cpudata[cpuid].irq_pending_hi != 0)
>>>>> + __ipipe_sync_stage(IPIPE_IRQMASK_ANY);
>>>>> }
>>>>> #ifdef CONFIG_IPIPE_TRACE_IRQSOFF
>>>>> ipipe_trace_end(0x8000000D);
>>>>
>>>>
>>>> Nope.
>>>
>>> That's good news, actually. I would have been quite embarrased if it did
>>> it.
>>>
>>>
>>>> Where should I put my finger on to find out what's happening?
>>>>
>>>
>>> It seems that the pipeline log is not synced by
>>> __ipipe_unstall_iret_root.
>>> We need to know why. Question: is the root stage stalled or unstalled by
>>> this
>>> routine during the latest call before the box freezes?
>>
>>
>> I'm currently switching my brain between to many tasks: Could you simply
>> tell me what variable to check so that I can hack some
>> ipipe_trace_special into the kernel?
>
> The value of the IPIPE_STALL_FLAG for the root domain upon exit from
> __ipipe_unstall_iret_root.
ipipe_root_domain->cpudata[cpuid].status is 0 on return.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply
* Re: accessing mirrired lvm on shared storage
From: Matthias Eble @ 2006-04-07 11:57 UTC (permalink / raw)
To: Chris Osicki; +Cc: linux-raid
In-Reply-To: <20060407134636.2bce1917@mwdsp001>
> Neil, you see the constantly growing number of potential users of this
> feature? ;-)
locking would be great (to me), indeed.
> PS Matthias, just curious, you don't have FC failover, right?
well, I have only 3 pci slots and can't use FC switches. the two boxes
(server and storage) run on different locations in the building (water
damages might be possible). Please tell me if you know a better way to
do the job.
thanks
^ permalink raw reply
* [Drbd-dev] about drbd "fencing" config option
From: Lars Ellenberg @ 2006-04-07 12:00 UTC (permalink / raw)
To: drbd-dev
/ 2006-04-06 11:15:02 -0600
\ Alan Robertson:
> Philipp Reisner wrote:
> >Hi,
> >Again an 8.0 pre release. There where _no_ actual bug reports
> >for the first pre release, so this release has no actual
> >bug fixes, only smoothing the rough edges:
> >8.0-pre2 (api:81/proto:80)
> >--------
> > * removed the "on-disconnect" and "split-brain-fix" config options and
> > added the "fencing" config option instead.
>
> What's a fencing option do?
configure how we behave when we think that "someone" should do fencing.
for example:
we are Connected Primary/Secondary
we lose replication channel
"fencing = DontCare" --> we just keep goin, we are the primary after all
this risks diverging data sets in case of split brain.
"fencing = resource" --> we invoke the "outdate-peer-handler",
which currently is a hackish script using ssh, but should
eventually become something that utilises heartbeat comunication
channels. heartbeat should not have stonith configured here, or
we risk that in the event of total communication loss -->
stonith the other node might win, and we might have acknowledged
transactions within the time period "connection loss" to "beeing
stonithed", that then will be gone.
"fencing = stonith"
we expect heartbeat to have stonith configured, so we will
freeze all io immediately, invoke the outdate-peer-handler, and
will only unfreeze io when this handler returns success --
or some higher authority explicitly unfreeze us.
the handler should attempt (or trigger) resource level fencing
first, (mark peer as "outdated") and fallback to stonith if
resource level fencing did not work out.
this could also be called the "oracle mode",
though orcale people probably want write-quorum >= 2,
which will be implemented someday, too.
stonith should, if configured, always be implemented as "switch off",
not as "reset", to avoid them stonithing each other.
if you configure drbd fencing=resource, but have stonith configured in
heartbeat, that is a configuration error.
if you configure drbd fencing=stonith, but have no stonith configured
in heartbeat, that will freeze io uneccessarily.
if you have fencing = resource, and no stonith configured, we need not
freeze io and still avoid diverging data sets even during total
communication loss: a secondary that has any doubt about the peers disk
state will refuse to become primary, whereas a primary that does not
know about its peers disk state will continue to be primary.
if after a cluster crash the cluster should come up without
communication, one cannot promote drbd to primary until communication
is restored or "some authority" explicitly assures one of the nodes
that the other node has been fenced.
if one node knows that the peers disk is "bad" (has been marked "outdated",
is "inconsistent"), this is stored in meta data, so that a degraded
cluster may crash/reboot and become primary anyways.
obviously we do not store "peers disk is good", that would be stupid.
--
: Lars Ellenberg Tel +43-1-8178292-55 :
: LINBIT Information Technologies GmbH Fax +43-1-8178292-82 :
: Schoenbrunner Str. 244, A-1120 Vienna/Europe http://www.linbit.com :
^ permalink raw reply
* [ALSA - driver 0001999]: Latest cvs won't compile
From: bugtrack @ 2006-04-07 12:12 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1999>
======================================================================
Reported By: kotau
Assigned To: perex
======================================================================
Project: ALSA - driver
Issue ID: 1999
Category: 0_compilation problem_!!!
Reproducibility: always
Severity: minor
Priority: normal
Status: assigned
Distribution:
Kernel Version: -2.6.13.2
======================================================================
Date Submitted: 04-03-2006 21:05 CEST
Last Modified: 04-07-2006 14:12 CEST
======================================================================
Summary: Latest cvs won't compile
Description:
Here's the error message.
==============
make[1]: Entering directory `/usr/src/linux-2.6.13.2'
CC [M] /usr/local/src/1music/alsa/alsa-driver/pci/ac97/ac97_proc.o
/usr/local/src/1music/alsa/alsa-driver/pci/ac97/ac97_proc.c: In function
`snd_ac97_proc_read_main':
/usr/local/src/1music/alsa/alsa-driver/pci/ac97/ac97_proc.c:122: error:
`snd_ac97_stereo_enhancements' undeclared (first use in this function)
/usr/local/src/1music/alsa/alsa-driver/pci/ac97/ac97_proc.c:122: error:
(Each undeclared identifier is reported only once
/usr/local/src/1music/alsa/alsa-driver/pci/ac97/ac97_proc.c:122: error:
for each function it appears in.)
/usr/local/src/1music/alsa/alsa-driver/pci/ac97/ac97_proc.c: In function
`snd_ac97_proc_read':
/usr/local/src/1music/alsa/alsa-driver/pci/ac97/ac97_proc.c:294: warning:
implicit declaration of function `snd_magic_cast'
/usr/local/src/1music/alsa/alsa-driver/pci/ac97/ac97_proc.c:294: error:
parse error before "ac97_t"
/usr/local/src/1music/alsa/alsa-driver/pci/ac97/ac97_proc.c:296: error:
structure has no member named `semaphore'
/usr/local/src/1music/alsa/alsa-driver/pci/ac97/ac97_proc.c:322: error:
structure has no member named `semaphore'
/usr/local/src/1music/alsa/alsa-driver/pci/ac97/ac97_proc.c: In function
`snd_ac97_proc_regs_read':
/usr/local/src/1music/alsa/alsa-driver/pci/ac97/ac97_proc.c:359: error:
parse error before "ac97_t"
/usr/local/src/1music/alsa/alsa-driver/pci/ac97/ac97_proc.c:361: error:
structure has no member named `semaphore'
/usr/local/src/1music/alsa/alsa-driver/pci/ac97/ac97_proc.c:377: error:
structure has no member named `semaphore'
make[5]: *** [/usr/local/src/1music/alsa/alsa-driver/pci/ac97/ac97_proc.o]
Error 1
make[4]: *** [/usr/local/src/1music/alsa/alsa-driver/pci/ac97] Error 2
make[3]: *** [/usr/local/src/1music/alsa/alsa-driver/pci] Error 2
make[2]: *** [_module_/usr/local/src/1music/alsa/alsa-driver] Error 2
make[1]: *** [modules] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.13.2'
======================================================================
----------------------------------------------------------------------
Raymond - 04-04-06 09:58
----------------------------------------------------------------------
snd_ac97_stereo_enhancements still exist in rev 1.17
http://cvs.sourceforge.net/viewcvs.py/*checkout*/alsa/alsa-kernel/pci/ac97/ac97_proc.c?rev=1.17
snd_magic_cast() had been removed
http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-kernel/pci/ac97/ac97_proc.c?r1=1.8&r2=1.9
Make sure your cvs is up-to-date
----------------------------------------------------------------------
Raymond - 04-07-06 14:12
----------------------------------------------------------------------
It seem to me that there is a problem on cvs
http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-utils/speaker-test/
speaker-test.c 1.25 8 days tiwai Summary: Remove loops after
errors Don't retry after fatal errors.
http://sourceforge.net/mailarchive/forum.php?thread_id=10120162&forum_id=33141
cvs -z3 update -P -d
cannot retrieve rev 1.26 of speaker-test
Issue History
Date Modified Username Field Change
======================================================================
04-03-06 21:05 kotau New Issue
04-03-06 21:05 kotau Kernel Version => -2.6.13.2
04-04-06 09:58 Raymond Note Added: 0009112
04-07-06 14:12 Raymond Note Added: 0009139
======================================================================
-------------------------------------------------------
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 0/2] scsi tgt updates (replace the elevator code)
From: James Bottomley @ 2006-04-07 12:20 UTC (permalink / raw)
To: Mike Christie; +Cc: FUJITA Tomonori, linux-scsi
In-Reply-To: <4435CABD.7000200@cs.wisc.edu>
On Thu, 2006-04-06 at 21:13 -0500, Mike Christie wrote:
> Hey James the patchset referred to in this mail, this patchset and the
> "[PATCH] scsi tgt: add task management function support" patch did not
> get merged to the tgt merged. Did you want us to resend the patchsets or
> did you not like them, or do you wnat them in one nice large patchset?
> Or did you want us to ask Jens to merge some of the not so controversial
> block layer stuff like "[PATCH 4/6] block layer: use blk_rq_bio_prep in
> init_request_from_bio" first? Thanks.
Yes, just resend them to linux-scsi, thanks. I'm going to be away for a
few days, so I'll probably get around to merging them on Wednesday or
so.
James
^ 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.