Make sure the state of a path is set properly when controller is swapped from passive to active

From: Babu Moger <[email protected]>

This patch adds LSI vendor and product ids in rdac device handler.

Signed-off-by Babu Moger <[email protected]>

---

From: Babu Moger <[email protected]>

This patch adds LSI vendor and product ids in rdac device handler.

Signed-off-by Babu Moger <[email protected]>

---

Thanks for the response.

If pg_init is intended to be called only once then problem is elsewhere.

During the pg_init, the activate_path is called. The activate_path calls scsi_dh_activate(then rdac_activate) which will set path state to active(h->state = RDAC_STATE_ACTIVE;). My understanding is, h->state is specific to each path. How does d-m sets h->state to RDAC_STATE_ACTIVE for all the paths available in the path group.

This is what happening in my case. On path group failure, d-m switches the path group initiates path group. It then selects the first path (in the path group) starts I/O. After exhausting the repeat_count it then selects the next path in the path group. Then rdac_prep_fn is called. This function finds h->state is still passive and fails the path which becomes unusable.

This function returns BLKPREP_KILL which is leading to fail failure.

static int rdac_prep_fn(struct scsi_device *sdev, struct request *req)

{
        struct rdac_dh_data *h = get_rdac_data(sdev);
        int ret = BLKPREP_OK;

        if (h->state != RDAC_STATE_ACTIVE) {
                ret = BLKPREP_KILL;
                req->cmd_flags |= REQ_QUIET;
        }
        return ret;
}

This is my understanding so far. Please correct me if there is anything wrong.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Alasdair G Kergon
Sent: Monday, November 10, 2008 6:59 PM
To: device-mapper development
Cc: [email protected]; [email protected]
Subject: Re: [dm-devel] DM does not activate the paths if there are more than one path in path group during failover

pg_init is a function intended to be called *once* when there is a switch to a new group of paths. It is not per-path initialisation.

Alasdair
--
[email protected]

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel

The problem reported by Moger Babu was caused due to the architectural change made when we moved from dm hardware handler to SCSI hardware handler.

Quoted 3 lines · Chandra Seetharaman

The problem reported by Moger Babu was caused due to the architectural change made when we moved from dm hardware handler to SCSI hardware handler.

pg_init is single initialisation for the group.
It only needs to happen on one path.

It sounds to me that what you're adding here is a *per-path* initialisation, something *separate* from (and additional to) the existing *per-group* pg_init.

Has this patch been tested on EMC?

Alasdair

No, I "replaced" the "per-group" pg_init with "per-path" init.

Quoted 1 line · Chandra Seetharaman

No, I "replaced" the "per-group" pg_init with "per-path" init.

Indeed, but I'm pointing out that the per-group initialisation was originally added for EMC and arguing that per-group initialisation and per-path initialisation are independent conceptually and the code may need to support both: adding one to deal with the problem reported here need not necessitate removing the other.

Alasdair

Hi All,
I have noticed one more problem with device mapper today.

Summary: If there are more than one path in the path group, device mapper does not activate the all the paths during the failover. DM only activates the first path in the path group. It does not call the function activate_path for the second path (or third so on). This seems like a major problem for me. Current code does not keep track of whether the path is already activated or not. This leads DM using only first path and all other paths become unusable. This happens during the failover.

Test case.
1. Start the IO with all the paths.
2. Fail the active path.
3. Failover (mode select) will happen and passive path will be activated
4. Only first path in path group is activated and other paths will be failed. I would expect the DM to activate all the paths in the path group. However this does not happen.

Output of multipath -ll before the test.

mpathf (3600a0b80000f519c0000cc8a48fc7d0b) dm-2 LSI,INF-01-00 [size=2.0G][features=0][hwhandler=1 rdac][rw]
\_ round-robin 0 [prio=4][enabled]
\_ 3:0:0:0 sde 8:64 [active][undef] running
\_ 3:0:2:0 sdg 8:96 [active][undef] running
\_ round-robin 0 [prio=2][enabled]
\_ 3:0:1:0 sdf 8:80 [active][undef] running
\_ 3:0:3:0 sdh 8:112 [active][undef] running

Output of multipath -ll after the test. Notice that second path has failed.

mpathf (3600a0b80000f519c0000cc8a48fc7d0b) dm-2 LSI,INF-01-00 [size=2.0G][features=0][hwhandler=1 rdac][rw]
\_ round-robin 0 [prio=2][enabled]
\_ 3:0:1:0 sdf 8:80 [active][undef] running
\_ 3:0:3:0 sdh 8:112 [failed][undef] running

Here is the patch, I have used to work-around the problem. I am sure this is not the place we want to add the fix. However, this patch should give you understanding of the problem. This patch will set the flags m->pg_init_required and m->queue_io whenever D-M select new path in the path group whenever the repeat_count is exhausted.

drivers/md/dm-mpath.c 2008-11-10 17:51:36.000000000 -0600 renamed from drivers/md/dm-mpath.c.orig 2008-11-10 17:50:24.000000000 -0600 +4 -0

@@ -245,6 +245,10 @@ static int __choose_path_in_pg(struct mu
        if (!path)
                return -ENXIO;
 
+       /* Set the pg_init_required flag to activate this path */
+       m->pg_init_required = 1;
+       m->queue_io = 1;
+
        m->current_pgpath = path_to_pgpath(path);
 
        if (m->current_pg != pg)

Hi All,
I have noticed one more problem with device mapper today.

Summary: If there are more than one path in the path group, device mapper does not activate the all the paths during the failover. DM only activates the first path in the path group. It does not call the function activate_path for the second path (or third so on). This seems like a major problem for me. Current code does not keep track of whether the path is already activated or not. This leads DM using only first path and all other paths become unusable. This happens during the failover.

Test case.
1. Start the IO with all the paths.
2. Fail the active path.
3. Failover (mode select) will happen and passive path will be
activated 4. Only first path in path group is activated and other paths will be failed. I would expect the DM to activate all the paths in the path group. However this does not happen.

Output of multipath -ll before the test.

mpathf (3600a0b80000f519c0000cc8a48fc7d0b) dm-2 LSI,INF-01-00 [size=2.0G][features=0][hwhandler=1 rdac][rw] \_ round-robin 0 [prio=4][enabled] \_ 3:0:0:0 sde 8:64 [active][undef] running \_ 3:0:2:0 sdg 8:96 [active][undef] running \_ round-robin 0 [prio=2][enabled] \_ 3:0:1:0 sdf 8:80 [active][undef] running \_ 3:0:3:0 sdh 8:112 [active][undef] running

Output of multipath -ll after the test. Notice that second path has failed.

mpathf (3600a0b80000f519c0000cc8a48fc7d0b) dm-2 LSI,INF-01-00 [size=2.0G][features=0][hwhandler=1 rdac][rw] \_ round-robin 0 [prio=2][enabled] \_ 3:0:1:0 sdf 8:80 [active][undef] running \_ 3:0:3:0 sdh 8:112 [failed][undef] running

Here is the patch, I have used to work-around the problem. I am sure
this is not the place we want to add the fix. However, this patch
should give you understanding of the problem. This patch will set the
flags
m->pg_init_required and m->queue_io whenever D-M select new path in the path group whenever the repeat_count is exhausted.

--- linux-2.6.28-rc4/drivers/md/dm-mpath.c.orig 2008-11-10 17:50:24.000000000 -0600
+++ linux-2.6.28-rc4/drivers/md/dm-mpath.c 2008-11-10 17:51:36.000000000 -0600

drivers/md/dm-mpath.c 2008-11-10 17:51:36.000000000 -0600 renamed from drivers/md/dm-mpath.c.orig 2008-11-10 17:50:24.000000000 -0600 +4 -0

@@ -245,6 +245,10 @@ static int __choose_path_in_pg(struct mu
        if (!path)
                return -ENXIO;
 
+       /* Set the pg_init_required flag to activate this path */
+       m->pg_init_required = 1;
+       m->queue_io = 1;
+
        m->current_pgpath = path_to_pgpath(path);
 
        if (m->current_pg != pg)

Is your multipathd running?
Yes, multipathd deamon is running.

BTW, why is the physical path state is showing "undef", it should be "ghost" or "ready"

This is because i am running the mainstream multipath-tools. That is the reason you are seeing "undef". I have reverted back to native tools and i am still seeing the problem. Here the output of multipath -ll with native tools.

mpathf (3600a0b80000f519c0000cc8a48fc7d0b) dm-2 LSI,INF-01-00 [size=2.0G][features=0][hwhandler=1 rdac]
\_ round-robin 0 [prio=0][active]
\_ 3:0:1:0 sdf 8:80 [active][ready]
\_ 3:0:3:0 sdh 8:112 [failed][ready]

-----Original Message-----
From: Chandra Seetharaman [mailto:[email protected]]
Sent: Monday, November 10, 2008 8:06 PM
To: Moger, Babu
Cc: [email protected]; device-mapper development; [email protected]
Subject: Re: DM does not activate the paths if there are more than one path in path group during failover

Quoted 4 lines · Babu

Hi All,
I have noticed one more problem with device mapper today.

Summary: If there are more than one path in the path group, device mapper does not activate the all the paths during the failover. DM only activates the first path in the path group. It does not call the function activate_path for the second path (or third so on). This seems like a major problem for me. Current code does not keep track of whether the path is already activated or not. This leads DM using only first path and all other paths become unusable. This happens during the failover.

We do not need to send activate to each "path" as all paths in a path group lead to the same controller and that controller is activated when the activate is sent on the first path itself.

Is your multipathd running ?

BTW, why is the physical path state is showing "undef", it should be "ghost" or "ready"

Quoted 38 lines

Test case.
1. Start the IO with all the paths.
2. Fail the active path.
3. Failover (mode select) will happen and passive path will be
activated 4. Only first path in path group is activated and other paths will be failed. I would expect the DM to activate all the paths in the path group. However this does not happen.

Output of multipath -ll before the test.

mpathf (3600a0b80000f519c0000cc8a48fc7d0b) dm-2 LSI,INF-01-00 [size=2.0G][features=0][hwhandler=1 rdac][rw] \_ round-robin 0 [prio=4][enabled] \_ 3:0:0:0 sde 8:64 [active][undef] running \_ 3:0:2:0 sdg 8:96 [active][undef] running \_ round-robin 0 [prio=2][enabled] \_ 3:0:1:0 sdf 8:80 [active][undef] running \_ 3:0:3:0 sdh 8:112 [active][undef] running

Output of multipath -ll after the test. Notice that second path has failed.

mpathf (3600a0b80000f519c0000cc8a48fc7d0b) dm-2 LSI,INF-01-00 [size=2.0G][features=0][hwhandler=1 rdac][rw] \_ round-robin 0 [prio=2][enabled] \_ 3:0:1:0 sdf 8:80 [active][undef] running \_ 3:0:3:0 sdh 8:112 [failed][undef] running

Here is the patch, I have used to work-around the problem. I am sure
this is not the place we want to add the fix. However, this patch
should give you understanding of the problem. This patch will set the
flags
m->pg_init_required and m->queue_io whenever D-M select new path in the path group whenever the repeat_count is exhausted.

--- linux-2.6.28-rc4/drivers/md/dm-mpath.c.orig 2008-11-10 17:50:24.000000000 -0600
+++ linux-2.6.28-rc4/drivers/md/dm-mpath.c 2008-11-10 17:51:36.000000000 -0600

drivers/md/dm-mpath.c 2008-11-10 17:51:36.000000000 -0600 static int __choose_path_in_pg(struct mu · line 254

Quoted 10 lines

drivers/md/dm-mpath.c 2008-11-10 17:51:36.000000000 -0600 renamed from drivers/md/dm-mpath.c.orig 2008-11-10 17:50:24.000000000 -0600 +4 -0

@@ -245,6 +245,10 @@ static int __choose_path_in_pg(struct mu
        if (!path)
                return -ENXIO;
 
+       /* Set the pg_init_required flag to activate this path */
+       m->pg_init_required = 1;
+       m->queue_io = 1;
+
        m->current_pgpath = path_to_pgpath(path);
 
        if (m->current_pg != pg)

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Is your multipathd running?
Yes, multipathd deamon is running.

BTW, why is the physical path state is showing "undef", it should be "ghost" or "ready"

This is because i am running the mainstream multipath-tools. That is the reason you are seeing "undef". I have reverted back to native tools and i am still seeing the problem. Here the output of multipath -ll with native tools.

mpathf (3600a0b80000f519c0000cc8a48fc7d0b) dm-2 LSI,INF-01-00 [size=2.0G][features=0][hwhandler=1 rdac]
\_ round-robin 0 [prio=0][active]
\_ 3:0:1:0 sdf 8:80 [active][ready]
\_ 3:0:3:0 sdh 8:112 [failed][ready]

-----Original Message-----
From: Chandra Seetharaman [mailto:[email protected]]
Sent: Monday, November 10, 2008 8:06 PM
To: Moger, Babu
Cc: [email protected]; device-mapper development; [email protected]
Subject: Re: DM does not activate the paths if there are more than one path in path group during failover

Quoted 4 lines · Babu

Hi All,
I have noticed one more problem with device mapper today.

Summary: If there are more than one path in the path group, device mapper does not activate the all the paths during the failover. DM only activates the first path in the path group. It does not call the function activate_path for the second path (or third so on). This seems like a major problem for me. Current code does not keep track of whether the path is already activated or not. This leads DM using only first path and all other paths become unusable. This happens during the failover.

We do not need to send activate to each "path" as all paths in a path group lead to the same controller and that controller is activated when the activate is sent on the first path itself.

Is your multipathd running ?

BTW, why is the physical path state is showing "undef", it should be "ghost" or "ready"

Quoted 38 lines

Test case.
1. Start the IO with all the paths.
2. Fail the active path.
3. Failover (mode select) will happen and passive path will be
activated 4. Only first path in path group is activated and other paths will be failed. I would expect the DM to activate all the paths in the path group. However this does not happen.

Output of multipath -ll before the test.

mpathf (3600a0b80000f519c0000cc8a48fc7d0b) dm-2 LSI,INF-01-00 [size=2.0G][features=0][hwhandler=1 rdac][rw] \_ round-robin 0 [prio=4][enabled] \_ 3:0:0:0 sde 8:64 [active][undef] running \_ 3:0:2:0 sdg 8:96 [active][undef] running \_ round-robin 0 [prio=2][enabled] \_ 3:0:1:0 sdf 8:80 [active][undef] running \_ 3:0:3:0 sdh 8:112 [active][undef] running

Output of multipath -ll after the test. Notice that second path has failed.

mpathf (3600a0b80000f519c0000cc8a48fc7d0b) dm-2 LSI,INF-01-00 [size=2.0G][features=0][hwhandler=1 rdac][rw] \_ round-robin 0 [prio=2][enabled] \_ 3:0:1:0 sdf 8:80 [active][undef] running \_ 3:0:3:0 sdh 8:112 [failed][undef] running

Here is the patch, I have used to work-around the problem. I am sure
this is not the place we want to add the fix. However, this patch
should give you understanding of the problem. This patch will set the
flags
m->pg_init_required and m->queue_io whenever D-M select new path in the path group whenever the repeat_count is exhausted.

--- linux-2.6.28-rc4/drivers/md/dm-mpath.c.orig 2008-11-10 17:50:24.000000000 -0600
+++ linux-2.6.28-rc4/drivers/md/dm-mpath.c 2008-11-10 17:51:36.000000000 -0600

drivers/md/dm-mpath.c 2008-11-10 17:51:36.000000000 -0600 static int __choose_path_in_pg(struct mu · line 254

Quoted 10 lines

drivers/md/dm-mpath.c 2008-11-10 17:51:36.000000000 -0600 renamed from drivers/md/dm-mpath.c.orig 2008-11-10 17:50:24.000000000 -0600 +4 -0

@@ -245,6 +245,10 @@ static int __choose_path_in_pg(struct mu
        if (!path)
                return -ENXIO;
 
+       /* Set the pg_init_required flag to activate this path */
+       m->pg_init_required = 1;
+       m->queue_io = 1;
+
        m->current_pgpath = path_to_pgpath(path);
 
        if (m->current_pg != pg)

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Hi All,
Have you guys seen this following error?

Jan 21 16:30:44 txmpp2 kernel: qla2xxx 0000:03:0c.0: Firmware image unavailable.
Jan 21 16:30:44 txmpp2 kernel: qla2xxx 0000:03:0c.0: Firmware images can be retrieved from: ftp://ftp.qlogic.com/outgoing/linux/firmware/.

After this error, qlogic driver fails to detect the LUNs attached.

I am running 2.6.29-rc2 kernel on x86_64 machine.

I tried couple of things without any success. I downloaded all the qlogic firmwares available and kept it in /lib/firmware. Tried rebuilding the kernel. Did not help. Thanks in advance.

Thanks
Babu Moger
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Hi All,
Have you guys seen this following error?

Jan 21 16:30:44 txmpp2 kernel: qla2xxx 0000:03:0c.0: Firmware image  
unavailable.
Jan 21 16:30:44 txmpp2 kernel: qla2xxx 0000:03:0c.0: Firmware images  

can be retrieved from: ftp://ftp.qlogic.com/outgoing/linux/firmware/.

After this error, qlogic driver fails to detect the LUNs attached.

I am running 2.6.29-rc2 kernel on x86_64 machine.

I tried couple of things without any success. I downloaded all the qlogic firmwares available and kept it in /lib/firmware. Tried rebuilding the kernel. Did not help. Thanks in advance.

Thanks
Babu Moger
--
To unsubscribe from this list: send the line "unsubscribe linux- scsi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Moger, Babu
Sent: Thursday, January 22, 2009 7:44 PM
To: Seokmann Ju
Cc: [email protected]; device-mapper development
Subject: RE: qla2xxx 0000:03:0c.0: Firmware image unavailable

Yes, the naming conventions look good. Here is the output of ls

(quoted diff) +0 -8

-rw-r--r-- 1 root root  76802 Jan 21 16:41 ql2100_fw.bin
-rw-r--r-- 1 root root  84566 Jan 21 16:41 ql2200_fw.bin
-rw-r--r-- 1 root root 125088 Jan 21 16:41 ql2300_fw.bin
-rw-r--r-- 1 root root 135896 Jan 21 16:41 ql2322_fw.bin
-rw-r--r-- 1 root root 228056 Jan 21 16:41 ql2400_fw.bin
-rw-r--r-- 1 root root 239052 Jan 21 16:41 ql2400_fw.bin_mid
-rw-r--r-- 1 root root 200064 Jan 21 16:41 ql2500_fw.bin
-rw-r--r-- 1 root root 219924 Jan 21 16:41 ql2500_fw.bin_mid

Thanks
Babu Moger

-----Original Message-----
From: Seokmann Ju [mailto:[email protected]]
Sent: Wednesday, January 21, 2009 6:26 PM
To: Moger, Babu
Cc: [email protected]; device-mapper development
Subject: Re: qla2xxx 0000:03:0c.0: Firmware image unavailable

Quoted 4 lines · Babu

Hi All,
Have you guys seen this following error?

Jan 21 16:30:44 txmpp2 kernel: qla2xxx 0000:03:0c.0: 

Firmware image

Quoted 2 lines

unavailable.

Jan 21 16:30:44 txmpp2 kernel: qla2xxx 0000:03:0c.0: 

Firmware images

Quoted 1 line

can be retrieved from:

ftp://ftp.qlogic.com/outgoing/linux/firmware/.

Quoted 8 lines

After this error, qlogic driver fails to detect the LUNs attached.

I am running 2.6.29-rc2 kernel on x86_64 machine.

I tried couple of things without any success. I downloaded all the qlogic firmwares available and kept it in /lib/firmware. Tried rebuilding the kernel. Did not help. Thanks in advance.

Could you double check that those firmware binaries under /lib/ firmware have correct naming convention as defined in qla_os.c:
FW_FILE_ISP2XXX?

Quoted 10 lines

Thanks
Babu Moger
--
To unsubscribe from this list: send the line "unsubscribe linux- scsi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Moger, Babu
Sent: Thursday, January 22, 2009 7:44 PM
To: Seokmann Ju
Cc: [email protected]; device-mapper development
Subject: RE: qla2xxx 0000:03:0c.0: Firmware image unavailable

Yes, the naming conventions look good. Here is the output of ls

(quoted diff) +0 -8

-rw-r--r-- 1 root root  76802 Jan 21 16:41 ql2100_fw.bin
-rw-r--r-- 1 root root  84566 Jan 21 16:41 ql2200_fw.bin
-rw-r--r-- 1 root root 125088 Jan 21 16:41 ql2300_fw.bin
-rw-r--r-- 1 root root 135896 Jan 21 16:41 ql2322_fw.bin
-rw-r--r-- 1 root root 228056 Jan 21 16:41 ql2400_fw.bin
-rw-r--r-- 1 root root 239052 Jan 21 16:41 ql2400_fw.bin_mid
-rw-r--r-- 1 root root 200064 Jan 21 16:41 ql2500_fw.bin
-rw-r--r-- 1 root root 219924 Jan 21 16:41 ql2500_fw.bin_mid

Thanks
Babu Moger

-----Original Message-----
From: Seokmann Ju [mailto:[email protected]]
Sent: Wednesday, January 21, 2009 6:26 PM
To: Moger, Babu
Cc: [email protected]; device-mapper development
Subject: Re: qla2xxx 0000:03:0c.0: Firmware image unavailable

Quoted 4 lines · Babu

Hi All,
Have you guys seen this following error?

Jan 21 16:30:44 txmpp2 kernel: qla2xxx 0000:03:0c.0: 

Firmware image

Quoted 2 lines

unavailable.

Jan 21 16:30:44 txmpp2 kernel: qla2xxx 0000:03:0c.0: 

Firmware images

Quoted 1 line

can be retrieved from:

ftp://ftp.qlogic.com/outgoing/linux/firmware/.

Quoted 8 lines

After this error, qlogic driver fails to detect the LUNs attached.

I am running 2.6.29-rc2 kernel on x86_64 machine.

I tried couple of things without any success. I downloaded all the qlogic firmwares available and kept it in /lib/firmware. Tried rebuilding the kernel. Did not help. Thanks in advance.

Could you double check that those firmware binaries under /lib/ firmware have correct naming convention as defined in qla_os.c:
FW_FILE_ISP2XXX?

Quoted 10 lines

Thanks
Babu Moger
--
To unsubscribe from this list: send the line "unsubscribe linux- scsi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

You are right. Looks like qlogic driver loads even before udev hotplug is functional. Driver loads successfully when I re-load the driver after the system in up. Is there any solution or work-around for this problem?

You are right. Looks like qlogic driver loads even before udev hotplug is functional. Driver loads successfully when I re-load the driver after the system in up. Is there any solution or work-around for this problem?

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Moger, Babu
Sent: Friday, January 23, 2009 5:46 AM
To: device-mapper development
Cc: [email protected]
Subject: RE: [dm-devel] RE: qla2xxx 0000:03:0c.0: Firmware image unavailable

Yes, firmware images are in the initrd. I have verified that.

Thanks
Babu Moger

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Dave Holland
Sent: Thursday, January 22, 2009 10:46 AM
To: device-mapper development
Cc: [email protected]
Subject: Re: [dm-devel] RE: qla2xxx 0000:03:0c.0: Firmware image unavailable

Quoted 1 line · Babu

You are right. Looks like qlogic driver loads even before

udev hotplug

Quoted 2 lines

is functional. Driver loads successfully when I re-load the driver after the system in up. Is there any solution or

work-around for this

Quoted 1 line

problem?

So the problem only happens at boot time? Are you using an initrd, and if so, have you got the firmware images in the initrd image?
(mkinitramfs, update-initramfs, etc)

Dave
--
** Dave Holland ** Systems Support -- Infrastructure Management ** ** 01223 496923 ** The Sanger Institute, Hinxton, Cambridge, UK ** "Your bumper is my crumple zone."

Signature · 14 lines

 The Wellcome Trust Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE. 

--
dm-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/dm-devel
--
To unsubscribe from this list: send the line "unsubscribe 
linux-scsi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

As James mentioned earlier, this is a distribution issue. I had seen this issue with redhat. If you observe redhat distro qlogic drivers, they compile firmware files along with the driver and hence they wouldn't observe this issue when they load through initrd as there is no firmware loading procedure through hotplug interface, whereas if you compile qlogic driver by hand without inbuilt firmware files and using distro's like redhat, you would encounter this issue. This has to be addressed in nash hotplug code.

Quoted 8 lines · Sudhakar Pannerselvam

As James mentioned earlier, this is a distribution issue. I had seen this issue with redhat. If you observe redhat distro qlogic drivers, they compile firmware files along with the driver and hence they wouldn't observe this issue when they load through initrd as there is no firmware loading procedure through hotplug interface, whereas if you compile qlogic driver by hand without inbuilt firmware files and using distro's like redhat, you would encounter this issue. This has to be addressed in nash hotplug code.

OK, there is one little wrinkle with Red Hat: nash is a sort of all in one process and it keeps going wrong. I've opened a few bugs with red hat about nash over the years with hotplug issues, which this is, but they always ignore them and then close them when the distro goes end of life.

These problems should be going away when Dave Jones finally kills off nash in his initrd/boot system rewrite.

Yes, firmware images are in the initrd. I have verified that.