Re: 2.6.14-rc5-mm1

Re: 2.6.14-rc5-mm1

[Andrew Morton]

Badari Pulavarty <pbadari@gmail.com> wrote:
>
> On Mon, 2005-10-24 at 01:48 -0700, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc5/2.6.14-rc5-mm1/
> > 
> 
> I can't seem to keep my AMD64 machine up with 2.6.14-rc5-mm1.
> Keep running into following. qlogic driver problem ?

I don't know why the qlogic driver has suddenly started doing this - were
there any earlier messages which might tell us?  Is it possible to increase
the debugging level?

I can spot one bug in there, but the lockup is just a symptom.

There are no qlogic changes in 2.6.14-rc5-mm1.

> Thanks,
> Badari
> 
> NMI Watchdog detected LOCKUP on CPU 0
> CPU 0
> Modules linked in: qlogicfc qla2300 qla2200 qla2xxx firmware_class
> ohci_hcd hw_r andom usbcore dm_mod
> Pid: 4414, comm: modprobe Not tainted 2.6.14-rc5-mm1 #3
> RIP: 0010:[<ffffffff80401d94>] <ffffffff80401d94>{.text.lock.spinlock
> +34}

That's a corrupted spinlock.

> RSP: 0000:ffff81019da91c28  EFLAGS: 00000086
> RAX: 0000000000000000 RBX: ffff81017991f288 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 0000000000000286 RDI: ffff81017991f290
> RBP: ffff81019da91c28 R08: 0000000000000034 R09: 0000000000000000
> R10: ffff81019da91c08 R11: 0000000000000000 R12: ffff81017991f290
> R13: 00000000fffffff4 R14: ffff81017991c000 R15: 0000000000000100
> FS:  00002aaaaade36e0(0000) GS:ffffffff80649800(0000)
> knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000000836018 CR3: 00000001bdf2a000 CR4: 00000000000006e0
> Process modprobe (pid: 4414, threadinfo ffff81019da90000, task
> ffff81019e3bb500)
> Stack: ffff81019da91cb8 ffffffff80400dec ffff81019da91c78
> ffffffff80142ed0
>        0000000000000000 0000000000000000 0000000000000001
> 0000000000000001
>        ffff81017991c000 0000000000000100
> Call Trace:<ffffffff80400dec>{wait_for_completion+28}
> <ffffffff80142ed0>{group_s end_sig_info+128}
>        <ffffffff80142f89>{kill_proc_info+73}
> <ffffffff8805753c>{:qla2xxx:qla2x00 _free_device+188}
>        <ffffffff8805880b>{:qla2xxx:qla2x00_probe_one+4187}
>        <ffffffff80132ce0>{set_cpus_allowed+336}
> <ffffffff8012dca3>{__wake_up_com mon+67}
>        <ffffffff8029741a>{kobject_get+26}
> <ffffffff8807c01d>{:qla2200:qla2200_pr obe_one+13}
>        <ffffffff802a516c>{pci_device_probe+252}
> <ffffffff80308d29>{driver_probe_ device+89}
>        <ffffffff80308da0>{__driver_attach+0}
> <ffffffff80308de2>{__driver_attach+ 66}
>        <ffffffff803086af>{bus_for_each_dev+79}
> <ffffffff80308bbc>{driver_attach+ 28}
>        <ffffffff80308108>{bus_add_driver+136}
> <ffffffff80308f0c>{driver_register +76}
>        <ffffffff802a4ebe>{pci_register_driver+158}
> <ffffffff8804d010>{:qla2200:q la2200_init+16}
>        <ffffffff80154072>{sys_init_module+274}
> <ffffffff8010dd2e>{system_call+12 6}

qla2x00_probe_one() has called qla2x00_free_device() and
qla2x00_free_device() has locked up in
wait_for_completion(&ha->dpc_exited);

Presumably, ha->dpc_exited is not initialised yet.

The first `goto probe_failed' in qla2x00_probe_one() will cause
qla2x00_free_device() to run wait_for_completion() against an uninitialised
completion struct.  Because ha->dpc_pid will be >= 0.

This patch might fix the lockup, but if so, qla2x00_iospace_config()
failed.  Please debug that a bit for us?

Andrew, this driver should be converted to use the kthread API - using
kill_proc() from within a driver to terminate a kernel thread is kinda
gross.


diff -puN drivers/scsi/qla2xxx/qla_os.c~qlogic-lockup-fix drivers/scsi/qla2xxx/qla_os.c
--- 25/drivers/scsi/qla2xxx/qla_os.c~qlogic-lockup-fix	Mon Oct 24 14:14:20 2005
+++ 25-akpm/drivers/scsi/qla2xxx/qla_os.c	Mon Oct 24 14:14:37 2005
@@ -1325,6 +1325,8 @@ int qla2x00_probe_one(struct pci_dev *pd
 	ha->brd_info = brd_info;
 	sprintf(ha->host_str, "%s_%ld", ha->brd_info->drv_name, ha->host_no);
 
+	ha->dpc_pid = -1;
+
 	/* Configure PCI I/O space */
 	ret = qla2x00_iospace_config(ha);
 	if (ret)
@@ -1448,7 +1450,6 @@ int qla2x00_probe_one(struct pci_dev *pd
 	 */
 	spin_lock_init(&ha->mbx_reg_lock);
 
-	ha->dpc_pid = -1;
 	init_completion(&ha->dpc_inited);
 	init_completion(&ha->dpc_exited);
 
_

Re: 2.6.14-rc5-mm1

[Badari Pulavarty]

On Mon, 2005-10-24 at 14:16 -0700, Andrew Morton wrote:
..
> 
> qla2x00_probe_one() has called qla2x00_free_device() and
> qla2x00_free_device() has locked up in
> wait_for_completion(&ha->dpc_exited);
> 
> Presumably, ha->dpc_exited is not initialised yet.
> 
> The first `goto probe_failed' in qla2x00_probe_one() will cause
> qla2x00_free_device() to run wait_for_completion() against an uninitialised
> completion struct.  Because ha->dpc_pid will be >= 0.
> 
> This patch might fix the lockup, but if so, qla2x00_iospace_config()
> failed.  Please debug that a bit for us?

Yes. This patch helped. Due to power failures, my disk trays are
powered off. qla2x00_iospace_config() is failing and causing the
panic on -mm kernel. For odd reasons, older -mm kernels & mainline
kernels doesn't panic.

Thanks,
Badari

Re: 2.6.14-rc5-mm1

[Christoph Hellwig]

On Mon, Oct 24, 2005 at 02:16:46PM -0700, Andrew Morton wrote:
> qla2x00_probe_one() has called qla2x00_free_device() and
> qla2x00_free_device() has locked up in
> wait_for_completion(&ha->dpc_exited);

one more reason to use one-for-one goto-style unwinding instead of
calling _free routines ;-)

While we're at it -  Andew, would you converting qla2xxx to the
kthread_ API for thread handling?

Re: 2.6.14-rc5-mm1

[Andrew Morton]

Badari Pulavarty <pbadari@gmail.com> wrote:
>
> On Mon, 2005-10-24 at 14:16 -0700, Andrew Morton wrote:
> ..
> > 
> > qla2x00_probe_one() has called qla2x00_free_device() and
> > qla2x00_free_device() has locked up in
> > wait_for_completion(&ha->dpc_exited);
> > 
> > Presumably, ha->dpc_exited is not initialised yet.
> > 
> > The first `goto probe_failed' in qla2x00_probe_one() will cause
> > qla2x00_free_device() to run wait_for_completion() against an uninitialised
> > completion struct.  Because ha->dpc_pid will be >= 0.
> > 
> > This patch might fix the lockup, but if so, qla2x00_iospace_config()
> > failed.  Please debug that a bit for us?
> 
> Yes. This patch helped. Due to power failures, my disk trays are
> powered off. qla2x00_iospace_config() is failing and causing the
> panic on -mm kernel. For odd reasons, older -mm kernels & mainline
> kernels doesn't panic.

OK, thanks.  Andrew seems offline and this patch is sufficiently obvious
that I think I'll just jam it into 2.6.14...

Re: 2.6.14-rc5-mm1

[Andrew Vasquez]

On Mon, 24 Oct 2005, Andrew Morton wrote:

> Badari Pulavarty <pbadari@gmail.com> wrote:
> >
> > On Mon, 2005-10-24 at 01:48 -0700, Andrew Morton wrote:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc5/2.6.14-rc5-mm1/
> > > 
> > 
> > I can't seem to keep my AMD64 machine up with 2.6.14-rc5-mm1.
> > Keep running into following. qlogic driver problem ?
> 
> I don't know why the qlogic driver has suddenly started doing this - were
> there any earlier messages which might tell us?  Is it possible to increase
> the debugging level?
> 
> I can spot one bug in there, but the lockup is just a symptom.
> 
> There are no qlogic changes in 2.6.14-rc5-mm1.
> 
> > Thanks,
> > Badari
> > 
> > NMI Watchdog detected LOCKUP on CPU 0
> > CPU 0
> > Modules linked in: qlogicfc qla2300 qla2200 qla2xxx firmware_class


qlogicfc attaches to both 2100 and 2200 ISPs.  It seems you're then
trying to load qla2xxx driver along with the 2300 and 2200 firmware
loader modules.  The pci_request_regions() call during 2200 probing
fails.

> > <ffffffff8010dd2e>{system_call+12 6}
> 
> qla2x00_probe_one() has called qla2x00_free_device() and
> qla2x00_free_device() has locked up in
> wait_for_completion(&ha->dpc_exited);
> 
> Presumably, ha->dpc_exited is not initialised yet.
> 

Causing this cleanup badness.

> The first `goto probe_failed' in qla2x00_probe_one() will cause
> qla2x00_free_device() to run wait_for_completion() against an uninitialised
> completion struct.  Because ha->dpc_pid will be >= 0.
> 
> This patch might fix the lockup, but if so, qla2x00_iospace_config()
> failed.  Please debug that a bit for us?

Badari, is there some reason you are using qlogicfc?  THe qla2xxx
driver supports all QLogic ISP parts.

> Andrew, this driver should be converted to use the kthread API - using
> kill_proc() from within a driver to terminate a kernel thread is kinda
> gross.

I'll look into this as well

Thanks,
Andrew Vasquez

Re: 2.6.14-rc5-mm1

[Badari Pulavarty]

On Thu, 2005-10-27 at 08:26 -0700, Andrew Vasquez wrote:
> On Mon, 24 Oct 2005, Andrew Morton wrote:
> 
> > Badari Pulavarty <pbadari@gmail.com> wrote:
> > >
> > > On Mon, 2005-10-24 at 01:48 -0700, Andrew Morton wrote:
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc5/2.6.14-rc5-mm1/
> > > > 
> > > 
> > > I can't seem to keep my AMD64 machine up with 2.6.14-rc5-mm1.
> > > Keep running into following. qlogic driver problem ?
> > 
> > I don't know why the qlogic driver has suddenly started doing this - were
> > there any earlier messages which might tell us?  Is it possible to increase
> > the debugging level?
> > 
> > I can spot one bug in there, but the lockup is just a symptom.
> > 
> > There are no qlogic changes in 2.6.14-rc5-mm1.
> > 
> > > Thanks,
> > > Badari
> > > 
> > > NMI Watchdog detected LOCKUP on CPU 0
> > > CPU 0
> > > Modules linked in: qlogicfc qla2300 qla2200 qla2xxx firmware_class
> 
> 
> qlogicfc attaches to both 2100 and 2200 ISPs.  It seems you're then
> trying to load qla2xxx driver along with the 2300 and 2200 firmware
> loader modules.  The pci_request_regions() call during 2200 probing
> fails.

Hmm. This is happening because I have both qlogicfc and qla2200 as
modules ?

> 
> > > <ffffffff8010dd2e>{system_call+12 6}
> > 
> > qla2x00_probe_one() has called qla2x00_free_device() and
> > qla2x00_free_device() has locked up in
> > wait_for_completion(&ha->dpc_exited);
> > 
> > Presumably, ha->dpc_exited is not initialised yet.
> > 
> 
> Causing this cleanup badness.
> 
> > The first `goto probe_failed' in qla2x00_probe_one() will cause
> > qla2x00_free_device() to run wait_for_completion() against an uninitialised
> > completion struct.  Because ha->dpc_pid will be >= 0.
> > 
> > This patch might fix the lockup, but if so, qla2x00_iospace_config()
> > failed.  Please debug that a bit for us?
> 
> Badari, is there some reason you are using qlogicfc?  THe qla2xxx
> driver supports all QLogic ISP parts.

Not intentionally. I have qla2200, qla2300 cards in my machine.
I build all the qlogic drivers as modules.

I hate to admit it - but I do use modules for qlogic disks.
I can't seem to compile the qlogic drivers (2200, 2300) into the
kernel and boot without problems (consistently on all my machines 
- I run into few issues):

(1) Between kernels, sometimes probing order changes and my local
disks get probed last and screws up my boot process - I don't
think this is a qlogic problem.

(2) Sometimes, one of the driver complains something like 
"PCI region already in use" and hangs on boot.

BTW, (2) happens even if its modules and I can't boot my
machine. Sometimes I had to boot with old kernel and hide
the modules - so boot process can't find them to workaround
the problem.

Is there a "dont-load-modules" option or don't load a specific
module option on boot ?

Thanks,
Badari

Re: 2.6.14-rc5-mm1

[Andrew Vasquez]

On Thu, 27 Oct 2005, Badari Pulavarty wrote:
> On Thu, 2005-10-27 at 08:26 -0700, Andrew Vasquez wrote:
> > qlogicfc attaches to both 2100 and 2200 ISPs.  It seems you're then
> > trying to load qla2xxx driver along with the 2300 and 2200 firmware
> > loader modules.  The pci_request_regions() call during 2200 probing
> > fails.
> 
> Hmm. This is happening because I have both qlogicfc and qla2200 as
> modules ?

Yes.  You don't need (unless there is a compeling reason) to compile
qlogicfc (CONFIG_SCSI_QLOGIC_FC) as the qla2xxx driver along with the
2200 and 2300 firmware mofules:

	CONFIG_SCSI_QLA2XXX=m
	CONFIG_SCSI_QLA22XX=m
	CONFIG_SCSI_QLA2300=m

will be fine.

> > Badari, is there some reason you are using qlogicfc?  THe qla2xxx
> > driver supports all QLogic ISP parts.
> 
> Not intentionally. I have qla2200, qla2300 cards in my machine.
> I build all the qlogic drivers as modules.

Could you send me your .config file?  I have a fealing you have and
entry similar to the following:

	CONFIG_SCSI_QLOGIC_FC=m

in there.  Don't compile the qlogicfc driver.

> I hate to admit it - but I do use modules for qlogic disks.

Thats fine.

> I can't seem to compile the qlogic drivers (2200, 2300) into the
> kernel and boot without problems (consistently on all my machines 
> - I run into few issues):
> 
> (1) Between kernels, sometimes probing order changes and my local
> disks get probed last and screws up my boot process - I don't
> think this is a qlogic problem.

Not sure there, but the removal of the qlogicfc driver could help
clear up some of the noise, like...

> (2) Sometimes, one of the driver complains something like 
> "PCI region already in use" and hangs on boot.

this.  the qlogicfc driver is being loaded before qla2xxx and the
supporting 2200 firmware module.

> BTW, (2) happens even if its modules and I can't boot my
> machine. Sometimes I had to boot with old kernel and hide
> the modules - so boot process can't find them to workaround
> the problem.
> 
> Is there a "dont-load-modules" option or don't load a specific
> module option on boot ?

--
Andrew Vasquez

Re: 2.6.14-rc5-mm1

[Christoph Hellwig]

On Thu, Oct 27, 2005 at 08:26:37AM -0700, Andrew Vasquez wrote:
> qlogicfc attaches to both 2100 and 2200 ISPs.  It seems you're then
> trying to load qla2xxx driver along with the 2300 and 2200 firmware
> loader modules.  The pci_request_regions() call during 2200 probing
> fails.

Btw, now that devfs is gone and thus DaveM's host renumbering issues
are modd we'd like to kill qlogicfc.  I vaguely remember people complaing
qla2xxx made trouble on qla2100 hardware.  Andrew do you have any success
or error reports for that hardware?

Re: 2.6.14-rc5-mm1

[Andrew Vasquez]

On Thu, 27 Oct 2005, Christoph Hellwig wrote:

> On Thu, Oct 27, 2005 at 08:26:37AM -0700, Andrew Vasquez wrote:
> > qlogicfc attaches to both 2100 and 2200 ISPs.  It seems you're then
> > trying to load qla2xxx driver along with the 2300 and 2200 firmware
> > loader modules.  The pci_request_regions() call during 2200 probing
> > fails.
> 
> Btw, now that devfs is gone and thus DaveM's host renumbering issues
> are modd we'd like to kill qlogicfc.  I vaguely remember people complaing
> qla2xxx made trouble on qla2100 hardware.  Andrew do you have any success
> or error reports for that hardware?

A couple of months ago I had worked with a 2100 user who was having
some serious problems within a configuration.  I was able to reproduce
something similar in-house and (to make a long-story, short), it turns
out there are some error-recovery problems in the firmware version
currently shipping in qla2xxx (1.19.25 TP firmware to be exact).

After numerous trial and error efforts, we were able to find a
reasonbly stable release with which the customer's configuration could
recover and run (1.17.38 EF, quite old).

In any case, formally, QLogic has dropped *all* support for ISP2100
cards, and thus, it's quite difficult to get any type of traction
from the firmware folk to begin to root-cause the failures.

I'm still in the process of ironing out the .bin distribution details
locally, but perhaps once we migrate to firmware-loading exclusively
via request_firmware(), the (small?) contigent of 2100 could use the
EF variant I referenced above.

Could I get another informal count of 2100 users who are still having
problems with qla2xxx?

Regards,
Andrew Vasquez

HEADS UP for QLA2100 users

[Christoph Hellwig]

On Thu, Oct 27, 2005 at 02:53:13PM -0700, Andrew Vasquez wrote:
> After numerous trial and error efforts, we were able to find a
> reasonbly stable release with which the customer's configuration could
> recover and run (1.17.38 EF, quite old).
> 
> In any case, formally, QLogic has dropped *all* support for ISP2100
> cards, and thus, it's quite difficult to get any type of traction
> from the firmware folk to begin to root-cause the failures.

Sure.  We're all very happy that you invest time to help these users
anyway, and will allow us to get rid of one more unmaintained driver.

> I'm still in the process of ironing out the .bin distribution details
> locally, but perhaps once we migrate to firmware-loading exclusively
> via request_firmware(), the (small?) contigent of 2100 could use the
> EF variant I referenced above.

You know, I'm in favour of getting firmware images in the kernel image,
but what's the problem of simply downgrading the 2100 firmware until
we get rid of the builtin firmware for all qla2xxx variants?

> Could I get another informal count of 2100 users who are still having
> problems with qla2xxx?

Re: HEADS UP for QLA2100 users

[Andrew Vasquez]

On Fri, 28 Oct 2005, Christoph Hellwig wrote:

> On Thu, Oct 27, 2005 at 02:53:13PM -0700, Andrew Vasquez wrote:
> 
> > I'm still in the process of ironing out the .bin distribution details
> > locally, but perhaps once we migrate to firmware-loading exclusively
> > via request_firmware(), the (small?) contigent of 2100 could use the
> > EF variant I referenced above.
> 
> You know, I'm in favour of getting firmware images in the kernel image,
> but what's the problem of simply downgrading the 2100 firmware until
> we get rid of the builtin firmware for all qla2xxx variants?

I have no problems with submitting 1.17.38 EF for inclusion upstream.
My only hope is that for the (other) 2100 user out there that use the
latest 2100 firmware and are not experiencing problems, the downgrade
does not break anything.

That's another reason I posed the following question:

> > Could I get another informal count of 2100 users who are still having
> > problems with qla2xxx?

Perhaps I should also ask:

	Who's running 2100 cards with the latest qla2xxx driver and
	are experiencing no problems?

--
AV

Re: HEADS UP for QLA2100 users

[Badari Pulavarty]

On Fri, 2005-10-28 at 16:03 -0700, Andrew Vasquez wrote:
> On Fri, 28 Oct 2005, Christoph Hellwig wrote:
> 
> > On Thu, Oct 27, 2005 at 02:53:13PM -0700, Andrew Vasquez wrote:
> > 
> > > I'm still in the process of ironing out the .bin distribution details
> > > locally, but perhaps once we migrate to firmware-loading exclusively
> > > via request_firmware(), the (small?) contigent of 2100 could use the
> > > EF variant I referenced above.
> > 
> > You know, I'm in favour of getting firmware images in the kernel image,
> > but what's the problem of simply downgrading the 2100 firmware until
> > we get rid of the builtin firmware for all qla2xxx variants?
> 
> I have no problems with submitting 1.17.38 EF for inclusion upstream.
> My only hope is that for the (other) 2100 user out there that use the
> latest 2100 firmware and are not experiencing problems, the downgrade
> does not break anything.
> 
> That's another reason I posed the following question:
> 
> > > Could I get another informal count of 2100 users who are still having
> > > problems with qla2xxx?
> 
> Perhaps I should also ask:
> 
> 	Who's running 2100 cards with the latest qla2xxx driver and
> 	are experiencing no problems?

Hmm.. I thought qla2xxx driver doesn't like qla2100. I had troubles
getting my qla2100 cards to work with qal2xxx (9 months ago) and
gave up and using only qla2200 and qla2300 card.

Is there a point in me going back and trying qla2100 ? (Ofcourse,
I need to locate those cards).

Thanks,
Badari

2.6.14-rc5-mm1: SAS: compile error with gcc 2.95

[Adrian Bunk]

On Mon, Oct 24, 2005 at 01:48:38AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.14-rc4-mm1:
>...
>  git-sas.patch
>...
>  Subsystem trees
>...

This gives the following compile error with gcc 2.95:

<--  snip  -->

...
  CC      drivers/scsi/aic94xx/aic94xx_init.o
In file included from include/scsi/sas/sas.h:90,
                 from include/scsi/sas/sas_class.h:33,
                 from include/scsi/sas/sas_discover.h:29,
                 from drivers/scsi/aic94xx/aic94xx.h:33,
                 from drivers/scsi/aic94xx/aic94xx_init.c:36:
include/scsi/sas/sas_frames.h:46: warning: unnamed struct/union that defines no instances
include/scsi/sas/sas_frames.h:47: warning: unnamed struct/union that defines no instances
include/scsi/sas/sas_frames.h:55: warning: unnamed struct/union that defines no instances
include/scsi/sas/sas_frames.h:70: warning: unnamed struct/union that defines no instances
include/scsi/sas/sas_frames.h:71: warning: unnamed struct/union that defines no instances
include/scsi/sas/sas_frames.h:79: warning: unnamed struct/union that defines no instances
In file included from include/scsi/sas/sas_frames.h:90,
                 from include/scsi/sas/sas.h:90,
                 from include/scsi/sas/sas_class.h:33,
                 from include/scsi/sas/sas_discover.h:29,
                 from drivers/scsi/aic94xx/aic94xx.h:33,
                 from drivers/scsi/aic94xx/aic94xx_init.c:36:
include/scsi/sas/sas_frames_le.h:51: warning: unnamed struct/union that defines no instances
include/scsi/sas/sas_frames_le.h:53: warning: unnamed struct/union that defines no instances
include/scsi/sas/sas_frames_le.h:63: warning: unnamed struct/union that defines no instances
include/scsi/sas/sas_frames_le.h:65: warning: unnamed struct/union that defines no instances
include/scsi/sas/sas_frames_le.h:219: warning: unnamed struct/union that defines no instances
In file included from drivers/scsi/aic94xx/aic94xx.h:33,
                 from drivers/scsi/aic94xx/aic94xx_init.c:36:
include/scsi/sas/sas_discover.h:157: warning: unnamed struct/union that defines no instances
include/scsi/sas/sas_discover.h: In function `sas_init_dev':
include/scsi/sas/sas_discover.h:201: structure has no member named `end_dev'
include/scsi/sas/sas_discover.h:201: structure has no member named `end_dev'
include/scsi/sas/sas_discover.h:201: structure has no member named `end_dev'
include/scsi/sas/sas_discover.h:201: structure has no member named `end_dev'
include/scsi/sas/sas_discover.h:205: structure has no member named `ex_dev'
include/scsi/sas/sas_discover.h:205: structure has no member named `ex_dev'
include/scsi/sas/sas_discover.h:205: structure has no member named `ex_dev'
include/scsi/sas/sas_discover.h:205: structure has no member named `ex_dev'
include/scsi/sas/sas_discover.h:210: structure has no member named `sata_dev'
include/scsi/sas/sas_discover.h:210: structure has no member named `sata_dev'
include/scsi/sas/sas_discover.h:210: structure has no member named `sata_dev'
include/scsi/sas/sas_discover.h:210: structure has no member named `sata_dev'
In file included from drivers/scsi/aic94xx/aic94xx_hwi.h:36,
                 from drivers/scsi/aic94xx/aic94xx_reg.h:32,
                 from drivers/scsi/aic94xx/aic94xx_init.c:37:
drivers/scsi/aic94xx/aic94xx_sas.h: At top level:
drivers/scsi/aic94xx/aic94xx_sas.h:363: warning: unnamed struct/union that defines no instances
drivers/scsi/aic94xx/aic94xx_sas.h:643: warning: unnamed struct/union that defines no instances
make[3]: *** [drivers/scsi/aic94xx/aic94xx_init.o] Error 1

<--  snip  -->

Since gcc 2.95 is a supported compiler for 2.6, the code has to be 
changed to compile with gcc 2.95.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.14-rc5-mm1: SAS: compile error with gcc 2.95

[Luben Tuikov]

--- Adrian Bunk <bunk@stusta.de> wrote:

> On Mon, Oct 24, 2005 at 01:48:38AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.14-rc4-mm1:
> >...
> >  git-sas.patch
> >...
> >  Subsystem trees
> >...
> 
> This gives the following compile error with gcc 2.95:
> 
> <--  snip  -->
> 
> ...
>   CC      drivers/scsi/aic94xx/aic94xx_init.o
> In file included from include/scsi/sas/sas.h:90,
>                  from include/scsi/sas/sas_class.h:33,
>                  from include/scsi/sas/sas_discover.h:29,
>                  from drivers/scsi/aic94xx/aic94xx.h:33,
>                  from drivers/scsi/aic94xx/aic94xx_init.c:36:
> include/scsi/sas/sas_frames.h:46: warning: unnamed struct/union that defines
> no instances
> include/scsi/sas/sas_frames.h:47: warning: unnamed struct/union that defines
> no instances
> include/scsi/sas/sas_frames.h:55: warning: unnamed struct/union that defines
> no instances
> include/scsi/sas/sas_frames.h:70: warning: unnamed struct/union that defines
> no instances
> include/scsi/sas/sas_frames.h:71: warning: unnamed struct/union that defines
> no instances
> include/scsi/sas/sas_frames.h:79: warning: unnamed struct/union that defines
> no instances
> In file included from include/scsi/sas/sas_frames.h:90,
>                  from include/scsi/sas/sas.h:90,
>                  from include/scsi/sas/sas_class.h:33,
>                  from include/scsi/sas/sas_discover.h:29,
>                  from drivers/scsi/aic94xx/aic94xx.h:33,
>                  from drivers/scsi/aic94xx/aic94xx_init.c:36:
> include/scsi/sas/sas_frames_le.h:51: warning: unnamed struct/union that
> defines no instances
> include/scsi/sas/sas_frames_le.h:53: warning: unnamed struct/union that
> defines no instances
> include/scsi/sas/sas_frames_le.h:63: warning: unnamed struct/union that
> defines no instances
> include/scsi/sas/sas_frames_le.h:65: warning: unnamed struct/union that
> defines no instances
> include/scsi/sas/sas_frames_le.h:219: warning: unnamed struct/union that
> defines no instances
> In file included from drivers/scsi/aic94xx/aic94xx.h:33,
>                  from drivers/scsi/aic94xx/aic94xx_init.c:36:
> include/scsi/sas/sas_discover.h:157: warning: unnamed struct/union that
> defines no instances
> include/scsi/sas/sas_discover.h: In function `sas_init_dev':
> include/scsi/sas/sas_discover.h:201: structure has no member named `end_dev'
> include/scsi/sas/sas_discover.h:201: structure has no member named `end_dev'
> include/scsi/sas/sas_discover.h:201: structure has no member named `end_dev'
> include/scsi/sas/sas_discover.h:201: structure has no member named `end_dev'
> include/scsi/sas/sas_discover.h:205: structure has no member named `ex_dev'
> include/scsi/sas/sas_discover.h:205: structure has no member named `ex_dev'
> include/scsi/sas/sas_discover.h:205: structure has no member named `ex_dev'
> include/scsi/sas/sas_discover.h:205: structure has no member named `ex_dev'
> include/scsi/sas/sas_discover.h:210: structure has no member named `sata_dev'
> include/scsi/sas/sas_discover.h:210: structure has no member named `sata_dev'
> include/scsi/sas/sas_discover.h:210: structure has no member named `sata_dev'
> include/scsi/sas/sas_discover.h:210: structure has no member named `sata_dev'
> In file included from drivers/scsi/aic94xx/aic94xx_hwi.h:36,
>                  from drivers/scsi/aic94xx/aic94xx_reg.h:32,
>                  from drivers/scsi/aic94xx/aic94xx_init.c:37:
> drivers/scsi/aic94xx/aic94xx_sas.h: At top level:
> drivers/scsi/aic94xx/aic94xx_sas.h:363: warning: unnamed struct/union that
> defines no instances
> drivers/scsi/aic94xx/aic94xx_sas.h:643: warning: unnamed struct/union that
> defines no instances
> make[3]: *** [drivers/scsi/aic94xx/aic94xx_init.o] Error 1
> 
> <--  snip  -->
> 
> Since gcc 2.95 is a supported compiler for 2.6, the code has to be 
> changed to compile with gcc 2.95.

Yes, I've been meaning to add names to unions to fix compilation with
gcc 2.95 for some time now.  Andrew has pointed that out to me before.

I'll submit a patch shortly.

     Luben


-- 
http://linux.adaptec.com/sas/
http://www.adaptec.com/sas/

Re: HEADS UP for QLA2100 users

[Adrian Bunk]

On Fri, Oct 28, 2005 at 04:35:43PM -0700, Badari Pulavarty wrote:
> On Fri, 2005-10-28 at 16:03 -0700, Andrew Vasquez wrote:
> > On Fri, 28 Oct 2005, Christoph Hellwig wrote:
> > 
> > > On Thu, Oct 27, 2005 at 02:53:13PM -0700, Andrew Vasquez wrote:
> > > 
> > > > I'm still in the process of ironing out the .bin distribution details
> > > > locally, but perhaps once we migrate to firmware-loading exclusively
> > > > via request_firmware(), the (small?) contigent of 2100 could use the
> > > > EF variant I referenced above.
> > > 
> > > You know, I'm in favour of getting firmware images in the kernel image,
> > > but what's the problem of simply downgrading the 2100 firmware until
> > > we get rid of the builtin firmware for all qla2xxx variants?
> > 
> > I have no problems with submitting 1.17.38 EF for inclusion upstream.
> > My only hope is that for the (other) 2100 user out there that use the
> > latest 2100 firmware and are not experiencing problems, the downgrade
> > does not break anything.
> > 
> > That's another reason I posed the following question:
> > 
> > > > Could I get another informal count of 2100 users who are still having
> > > > problems with qla2xxx?
> > 
> > Perhaps I should also ask:
> > 
> > 	Who's running 2100 cards with the latest qla2xxx driver and
> > 	are experiencing no problems?
> 
> Hmm.. I thought qla2xxx driver doesn't like qla2100. I had troubles
> getting my qla2100 cards to work with qal2xxx (9 months ago) and
> gave up and using only qla2200 and qla2300 card.
> 
> Is there a point in me going back and trying qla2100 ? (Ofcourse,
> I need to locate those cards).

Now that in 2.6.16-rc the recommended method for firmware loading in
qla2xxx is to load it from userspace, the firmware version problems 
should have become non-issues.

If ypu have hardware that works in 2.6.16-rc2 with the qlogicfc driver 
but not with the qal2xxx driver, a bug report would be appreciated.

> Thanks,
> Badari

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

[2.6 patch] schedule the SCSI qlogicfc driver for removal

[Adrian Bunk]

As usual, there isn't much feedback regarding problems with one driver 
from people using an obsolete driver for the same hardware.

So schedule the SCSI qlogicfc driver for removal and let the 
flames^Wfeedback begin...


Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 Documentation/feature-removal-schedule.txt |    7 +++++++
 drivers/scsi/qlogicfc.c                    |    1 +
 2 files changed, 8 insertions(+)

--- linux-2.6.16-rc2-mm1-full/Documentation/feature-removal-schedule.txt.old	2006-02-14 00:26:21.000000000 +0100
+++ linux-2.6.16-rc2-mm1-full/Documentation/feature-removal-schedule.txt	2006-02-14 00:28:12.000000000 +0100
@@ -153,0 +154,7 @@
+What:   SCSI qlogicfc driver
+When:   August 2006
+Why:    replaced by the qla2xxx driver
+Who:    Adrian Bunk <bunk@stusta.de>
+
+---------------------------
+
--- linux-2.6.16-rc2-mm1-full/drivers/scsi/qlogicfc.c.old	2006-02-14 00:29:41.000000000 +0100
+++ linux-2.6.16-rc2-mm1-full/drivers/scsi/qlogicfc.c	2006-02-14 00:34:43.000000000 +0100
@@ -724,6 +724,7 @@
 	dma_addr_t busaddr;
 	int i;
 
+	printk(KERN_WARNING "qlogicfc will be removed soon, please use the qla2xxx driver\n");
 
 	ENTER("isp2x00_detect");
 

Re: [2.6 patch] schedule the SCSI qlogicfc driver for removal

[Christoph Hellwig]

On Tue, Feb 14, 2006 at 01:14:09AM +0100, Adrian Bunk wrote:
> As usual, there isn't much feedback regarding problems with one driver 
> from people using an obsolete driver for the same hardware.
> 
> So schedule the SCSI qlogicfc driver for removal and let the 
> flames^Wfeedback begin...

The driver has been deprecatedd since long before the official deprecation
mechanisms existed.  It'll go away for 2.6.17.

Re: [2.6 patch] schedule the SCSI qlogicfc driver for removal

[Adrian Bunk]

On Tue, Feb 14, 2006 at 05:43:09PM +0000, Christoph Hellwig wrote:
> On Tue, Feb 14, 2006 at 01:14:09AM +0100, Adrian Bunk wrote:
> > As usual, there isn't much feedback regarding problems with one driver 
> > from people using an obsolete driver for the same hardware.
> > 
> > So schedule the SCSI qlogicfc driver for removal and let the 
> > flames^Wfeedback begin...
> 
> The driver has been deprecatedd since long before the official deprecation
> mechanisms existed.  It'll go away for 2.6.17.

Is this patch pending somewhere or should I send a patch?

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed