On 08/08/10 11:08 PM, Giuseppe Corazzin wrote:
> Spett.le Cliente,
>
> dal 9 Agosto 2010 al 29 Agosto 2010UT non sarò in grado di leggere le email inviate a questo indirizzo.
> Per urgenze compilare il form sul nuovo sito della Computer srlhttp://www.computersrl.com/home/component/jforms/4/88.html
> o chiamare il numero 0438.450500

Dear Customer,

from 9 August 2010 to 29 August 2010UT not be able to read emails sent
to this address.
For emergencies please fill the form on ....



its an Out Of Office message :-/



_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

2010/8/9 Rajagopal Swaminathan <raju.rajsand@gmail.com>:
> 2010/8/9 Giuseppe Corazzin <giuseppe@computersrl.com>:
>
> duh.. I cant understand a word of it. and won't bother with translation.
>
> English please.Rest are irritating in a tech list.

It's spam!
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

have done updations. look forward to it now
*K@NZ@




_______________________________________________
design-team mailing list
design-team@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/design-team

On 09/27/2010 08:14 PM, kanza aman wrote:
>
> have done updations. look forward to it now

You have a small typo, year "20010".

Please in the future don't sent such large attachments to the list,
upload the files somewhere (your fedorapeople account, the wiki, etc.)
and pass a link.

--
nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/

_______________________________________________
design-team mailing list
design-team@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/design-team

http://equitation-accordee.com/to.php



_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Hello again,
I sent this yesterday but since I wasn't a member maybe it didn't go anywhere.

Hello,
I'm trying to debug an issue using crash. I've moved the vmcore file over to a system other than the system from which the dump was collected. I've installed a variety of debug rpms including the kernel-debuginfo, kernel-debug-debuginfo, glib-debuginfo, and kernel-debuginfo-common. I've also copied the lib/modules from the test system to mine.

When I run the command "p hba" it returns:

Crash > p hba
Hba = $2 = 778764288 (please ignore the uppercase, stupid mail client)

I expect to see something like:

Hba = $1 = {0x102170b0000, 0x0, 0x0,..., 0x0}

Why is that? Do I need to be running crash on the test system itself? I thought all relevant info would be contained in the vmcore file and I could attempt the analysis on any system?.

The crash version command returns version = $3 = v0.25941.
My running kernel is 2.6.18-prep. /etc/issue reports rhel5.5.
The kernel on the test system is 2.6.18-164.el5. That is also the version of the debug packages I installed as well as the vmlinux file I'm using. Any problems mixing and matching like that? I have not rebooted my system since installing the debug packages but that doesn't seem necessary. Thanks in advance.

-- mikem




--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

----- "Mike Miller (OS Dev)" <Mike.Miller@hp.com> wrote:

> Hello again,
> I sent this yesterday but since I wasn't a member maybe it didn't go
> anywhere.

Hi Mike,

I accepted your message:

https://www.redhat.com/archives/crash-utility/2010-October/msg00052.html

and answered it here:

https://www.redhat.com/archives/crash-utility/2010-October/msg00053.html

Dave


> Hello,
> I'm trying to debug an issue using crash. I've moved the vmcore file
> over to a system other than the system from which the dump was
> collected. I've installed a variety of debug rpms including the
> kernel-debuginfo, kernel-debug-debuginfo, glib-debuginfo, and
> kernel-debuginfo-common. I've also copied the lib/modules from the
> test system to mine.
>
> When I run the command "p hba" it returns:
>
> Crash > p hba
> Hba = $2 = 778764288 (please ignore the uppercase, stupid mail client)
>
> I expect to see something like:
>
> Hba = $1 = {0x102170b0000, 0x0, 0x0,..., 0x0}
>
> Why is that? Do I need to be running crash on the test system itself?
> I thought all relevant info would be contained in the vmcore file and
> I could attempt the analysis on any system?.
>
> The crash version command returns version = $3 = v0.25941.
> My running kernel is 2.6.18-prep. /etc/issue reports rhel5.5.
> The kernel on the test system is 2.6.18-164.el5. That is also the
> version of the debug packages I installed as well as the vmlinux file
> I'm using. Any problems mixing and matching like that? I have not
> rebooted my system since installing the debug packages but that
> doesn't seem necessary. Thanks in advance.
>
> -- mikem

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

_______________________________________________
design-team mailing list
design-team@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/design-team

diff --git a/drivers/md/dm-mpath.c b/drivers/md/dm-mpath.c
index 487ecda..723dc19 100644
--- a/drivers/md/dm-mpath.c
+++ b/drivers/md/dm-mpath.c
@@ -56,8 +56,14 @@ struct priority_group {
struct list_head pgpaths;
};

+/*
+ * Bits for the m->features
+ */
+#define MPF_ABORT_QUEUE 0
+
/* Multipath context */
struct multipath {
+ unsigned long features;
struct list_head list;
struct dm_target *ti;

@@ -813,6 +819,11 @@ static int parse_features(struct arg_set *as, struct multipath *m)
continue;
}

+ if (!strnicmp(param_name, MESG_STR("abort_queue_on_fail"))) {
+ set_bit(MPF_ABORT_QUEUE, &m->features);
+ continue;
+ }
+
if (!strnicmp(param_name, MESG_STR("pg_init_retries")) &&
(argc >= 1)) {
r = read_param(_params + 1, shift(as),
@@ -995,7 +1006,9 @@ static int fail_path(struct pgpath *pgpath)
pgpath->path.dev->name, m->nr_valid_paths);

schedule_work(&m->trigger_event);
- queue_work(kmultipathd, &pgpath->deactivate_path);
+
+ if (test_bit(MPF_ABORT_QUEUE, &pgpath->pg->m->features))
+ queue_work(kmultipathd, &pgpath->deactivate_path);

out:
spin_unlock_irqrestore(&m->lock, flags);
@@ -1382,11 +1395,14 @@ static int multipath_status(struct dm_target *ti, status_type_t type,
DMEMIT("2 %u %u ", m->queue_size, m->pg_init_count);
else {
DMEMIT("%u ", m->queue_if_no_path +
- (m->pg_init_retries > 0) * 2);
+ (m->pg_init_retries > 0) * 2 +
+ test_bit(MPF_ABORT_QUEUE, &m->features));
if (m->queue_if_no_path)
DMEMIT("queue_if_no_path ");
if (m->pg_init_retries)
DMEMIT("pg_init_retries %u ", m->pg_init_retries);
+ if (test_bit(MPF_ABORT_QUEUE, &m->features))
+ DMEMIT("abort_queue_on_fail ");
}

if (!m->hw_handler_name || type == STATUSTYPE_INFO)
@@ -1490,6 +1506,10 @@ static int multipath_message(struct dm_target *ti, unsigned argc, char **argv)
} else if (!strnicmp(argv[0], MESG_STR("fail_if_no_path"))) {
r = queue_if_no_path(m, 0, 0);
goto out;
+ } else if (!strnicmp(argv[0], MESG_STR("skip_abort_queue_on_fail"))) {
+ clear_bit(MPF_ABORT_QUEUE, &m->features);
+ r = 0;
+ goto out;
}
}

@@ -1655,7 +1675,7 @@ out:
*---------------------------------------------------------------*/
static struct target_type multipath_target = {
.name = "multipath",
- .version = {1, 1, 1},
+ .version = {1, 2, 0},
.module = THIS_MODULE,
.ctr = multipath_ctr,
.dtr = multipath_dtr,

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

please ignore this patch...

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel