Boaz Harrosh | 1 Nov 11:15 2009

Re: [PATCH] Add missing #include for include/scsi/osd_protocol.h

On 10/31/2009 11:33 AM, Martin Michlmayr wrote:
> include/scsi/osd_protocol.h is missing an #include, leading to:
> | include/scsi/osd_protocol.h:277: error: implicit declaration of function '__constant_cpu_to_be16'
> | include/scsi/osd_protocol.h:362: error: implicit declaration of function 'ALIGN'
> 

I cannot reproduce this problem. What platform  (ARCH/config) are you compiling
this?

Because you see I have a source file in the tree that has this #include as very
first include. And it has been compiling in Kernel and in -next for a long time.
(drivers/scsi/osd/osd_initiator.c has osd_initiator.h as first header which has
 osd_protocol.h as first header.)

> Signed-off-by: Martin Michlmayr <tbm <at> cyrius.com>
> 
> --- a/include/scsi/osd_protocol.h	2009-10-31 09:19:28.000000000 +0000
> +++ b/include/scsi/osd_protocol.h	2009-10-31 09:27:42.000000000 +0000
>  <at>  <at>  -17,6 +17,7  <at>  <at> 
>  #define __OSD_PROTOCOL_H__
>  
>  #include <linux/types.h>
> +#include <linux/kernel.h>
>  #include <asm/unaligned.h>

From what I can see, asm/unaligned.h eventually pulls kernel.h through
one of it's possible implementations. Do you have a special asm/unaligned.h?

>  #include <scsi/scsi.h>
>  
(Continue reading)

Martin Michlmayr | 1 Nov 11:54 2009

Re: [PATCH] Add missing #include for include/scsi/osd_protocol.h

* Boaz Harrosh <bharrosh <at> panasas.com> [2009-11-01 12:15]:
> > include/scsi/osd_protocol.h is missing an #include, leading to:
> > | include/scsi/osd_protocol.h:277: error: implicit declaration of function '__constant_cpu_to_be16'
> > | include/scsi/osd_protocol.h:362: error: implicit declaration of function 'ALIGN'
> 
> I cannot reproduce this problem. What platform  (ARCH/config) are you compiling
> this?

Sorry, I forgot to say that this happens on ARM.
--

-- 
Martin Michlmayr
http://www.cyrius.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Boaz Harrosh | 1 Nov 12:25 2009

Re: [PATCH] Add missing #include for include/scsi/osd_protocol.h

On 11/01/2009 12:54 PM, Martin Michlmayr wrote:
> * Boaz Harrosh <bharrosh <at> panasas.com> [2009-11-01 12:15]:
>>> include/scsi/osd_protocol.h is missing an #include, leading to:
>>> | include/scsi/osd_protocol.h:277: error: implicit declaration of function '__constant_cpu_to_be16'
>>> | include/scsi/osd_protocol.h:362: error: implicit declaration of function 'ALIGN'
>>
>> I cannot reproduce this problem. What platform  (ARCH/config) are you compiling
>> this?
> 
> Sorry, I forgot to say that this happens on ARM.

Yes I can see now linux/unaligned/le_byteshift.h and linux/unaligned/be_byteshift.h look
broken, they do not include headers who's definitions are used. All the other alternatives
in linux/unaligned/ ,example access_ok.h, do. Sigh

But one thing I do not understand, in linux-next is there not a single ARM platform that
does a "make allmodconfig". (Or they do but the compilation error was never reported?)

ACK-by: Boaz Harrosh <bharrosh <at> panasas.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Stephen Rothwell | 1 Nov 12:52 2009
Picon
Picon

Re: [PATCH] Add missing #include for include/scsi/osd_protocol.h

Hi Boaz,

On Sun, 01 Nov 2009 13:25:43 +0200 Boaz Harrosh <bharrosh <at> panasas.com> wrote:
>
> Yes I can see now linux/unaligned/le_byteshift.h and linux/unaligned/be_byteshift.h look
> broken, they do not include headers who's definitions are used. All the other alternatives
> in linux/unaligned/ ,example access_ok.h, do. Sigh
> 
> But one thing I do not understand, in linux-next is there not a single ARM platform that
> does a "make allmodconfig". (Or they do but the compilation error was never reported?)

The arm allmodconfig is really a non starter I am told (allmodconfig is
really per arch, not per platform).  However you can see all the
linux-next build results for arm (and lots of others) at
http://kisskb.ellerman.id.au/kisskb/branch/9/ .  I often don't have time
to review the build results - I assume that other people with an interest
will do so.

--

-- 
Cheers,
Stephen Rothwell                    sfr <at> canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
Boaz Harrosh | 1 Nov 14:11 2009

Re: [PATCH] Add missing #include for include/scsi/osd_protocol.h

On 11/01/2009 01:52 PM, Stephen Rothwell wrote:
> Hi Boaz,
> 
> On Sun, 01 Nov 2009 13:25:43 +0200 Boaz Harrosh <bharrosh <at> panasas.com> wrote:
>>
>> Yes I can see now linux/unaligned/le_byteshift.h and linux/unaligned/be_byteshift.h look
>> broken, they do not include headers who's definitions are used. All the other alternatives
>> in linux/unaligned/ ,example access_ok.h, do. Sigh
>>
>> But one thing I do not understand, in linux-next is there not a single ARM platform that
>> does a "make allmodconfig". (Or they do but the compilation error was never reported?)
> 
> The arm allmodconfig is really a non starter I am told (allmodconfig is
> really per arch, not per platform).  However you can see all the
> linux-next build results for arm (and lots of others) at
> http://kisskb.ellerman.id.au/kisskb/branch/9/ .  I often don't have time
> to review the build results - I assume that other people with an interest
> will do so.
> 

From the list you've sent (above), there is not a single ARM platform
that does an allXXXconfig. They are all a "defconfig". I'll bear that
in mind next time.

(Time for that arm cross compiler)

Thanks
Boaz
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
(Continue reading)

Boaz Harrosh | 1 Nov 17:43 2009

[PATCH 4/5 version 2] osduld: Use device->release instead of internal kref


The true logic of this patch will be clear in the next patch where we
use the class_find_device() API. When doing so the use of an internal
kref leaves us a narrow window where a find is started while the actual
object can go away. Using the device's kobj reference solves this
problem because now the same kref is used for both operations. (Remove
and find)

Core changes
* Embed a struct device in uld_ structure and use device_register
  instead of devie_create. Set __remove to be the device release
  function.
* __uld_get/put is just get_/put_device. Now everything is accounted
  for on the device object. Internal kref is removed.
* At __remove() we can safely de-allocate the uld_ structure. (The
  function was moved to avoid forward declaration)

Some cleanups
* Use class register/unregister is cleaner for this driver now.
* cdev ref-counting games are no longer necessary

I have incremented the device version string in case of new bugs.

Note: Previous bugfix of taking the reference around fput() still
      applies.

Signed-off-by: Boaz Harrosh <bharrosh <at> panasas.com>
---
 drivers/scsi/osd/osd_uld.c   |  162 ++++++++++++++++++++----------------------
 include/scsi/osd_initiator.h |    1 -
(Continue reading)

Boaz Harrosh | 1 Nov 17:45 2009

[PATCH 5/5 version2] libosd: osd_dev_info: Unique Identification of an OSD device


Define an osd_dev_info structure that Uniquely identifies an OSD
device lun on the network. The identification is built from unique
target attributes and is the same for all network/SAN machines.

osduld_info_lookup() - NEW
    New API that will lookup an osd_dev by its osd_dev_info.
    This is used by pNFS-objects for cross network global device
    identification. And by exofs multy-device support, the device
    info is specified in the on-disk exofs device table.

osduld_device_info() - NEW
    Given an osd_dev handle returns its associated osd_dev_info.
    The ULD fetches this information at startup and hangs it on
    each OSD device. (This is a fast operation that can be called
    at any condition)

osduld_device_same() - NEW
    With a given osd_dev at one hand and an osd_dev_info
    at another, we would like to know if they are the same
    device.
    Two osd_dev handles can be checked by:
        osduld_device_same(od1, osduld_device_info(od2));

osd_auto_detect_ver() - REVISED
    Now returns an osd_dev_info structure. Is only called once
    by ULD as before. See added comments for how to use.

Signed-off-by: Boaz Harrosh <bharrosh <at> panasas.com>
---
(Continue reading)

Thomas Fjellstrom | 1 Nov 20:16 2009
Picon

raid disk failure, options?

My main raid array just had a disk failure. I tried to hot remove the 
device, and use the scsi bus rescan sysfs entries, but it seems to fail on 
IDENTIFY.

Can I assume my disk is dead?

[5015721.851044] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0                                                                                                                                                                  
[5015721.851089] ata3.00: irq_stat 0x40000001                                                                                                                                                                                               
[5015721.851124] ata3.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0                                                                                                                                                                     
[5015721.851125]          res 71/04:03:80:01:32/00:00:00:00:00/e0 Emask 0x1 
(device error)                                                                                                                                                  
[5015721.851193] ata3.00: status: { DRDY DF ERR }                                                                                                                                                                                           
[5015721.851225] ata3.00: error: { ABRT }                                                                                                                                                                                                   
[5015726.848684] ata3.00: qc timeout (cmd 0xec)                                                                                                                                                                                             
[5015726.848729] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x5)                                                                                                                                                                      
[5015726.848763] ata3.00: revalidation failed (errno=-5)                                                                                                                                                                                    
[5015726.848798] ata3: hard resetting link                                                                                                                                                                                                  
[5015734.501527] ata3: softreset failed (device not ready)                                                                                                                                                                                  
[5015734.501565] ata3: failed due to HW bug, retry pmp=0                                                                                                                                                                                    
[5015734.665530] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)                                                                                                                                                                     
[5015734.707085] ata3.00: both IDENTIFYs aborted, assuming NODEV                                                                                                                                                                            
[5015734.707089] ata3.00: revalidation failed (errno=-2)                                                                                                                                                                                    
[5015739.664923] ata3: hard resetting link                                                                                                                                                                                                  
[5015740.148277] ata3: softreset failed (device not ready)                                                                                                                                                                                  
[5015740.148314] ata3: failed due to HW bug, retry pmp=0                                                                                                                                                                                    
[5015740.313532] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[5015740.337129] ata3.00: both IDENTIFYs aborted, assuming NODEV
[5015740.337132] ata3.00: revalidation failed (errno=-2)
[5015740.337167] ata3.00: disabled
[5015740.337231] ata3: EH complete
(Continue reading)

Justin Piszcz | 2 Nov 00:19 2009

Re: raid disk failure, options?


On Sun, 1 Nov 2009, Thomas Fjellstrom wrote:

> My main raid array just had a disk failure. I tried to hot remove the
> device, and use the scsi bus rescan sysfs entries, but it seems to fail on
> IDENTIFY.
>
> Can I assume my disk is dead?
>
>
> [5015721.851044] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
> [5015721.851089] ata3.00: irq_stat 0x40000001
> [5015721.851124] ata3.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
> [5015721.851125]          res 71/04:03:80:01:32/00:00:00:00:00/e0 Emask 0x1
> (device error)
> [5015721.851193] ata3.00: status: { DRDY DF ERR }
> [5015721.851225] ata3.00: error: { ABRT }
> [5015726.848684] ata3.00: qc timeout (cmd 0xec)
> [5015726.848729] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x5)
> [5015726.848763] ata3.00: revalidation failed (errno=-5)
> [5015726.848798] ata3: hard resetting link
> [5015734.501527] ata3: softreset failed (device not ready)
> [5015734.501565] ata3: failed due to HW bug, retry pmp=0
> [5015734.665530] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [5015734.707085] ata3.00: both IDENTIFYs aborted, assuming NODEV
> [5015734.707089] ata3.00: revalidation failed (errno=-2)
> [5015739.664923] ata3: hard resetting link
> [5015740.148277] ata3: softreset failed (device not ready)
> [5015740.148314] ata3: failed due to HW bug, retry pmp=0
> [5015740.313532] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
(Continue reading)

Thomas Fjellstrom | 2 Nov 00:45 2009
Picon

Re: raid disk failure, options?

On Sun November 1 2009, Justin Piszcz wrote:
> On Sun, 1 Nov 2009, Thomas Fjellstrom wrote:
> > My main raid array just had a disk failure. I tried to hot remove the
> > device, and use the scsi bus rescan sysfs entries, but it seems to fail
> > on IDENTIFY.
> >
> > Can I assume my disk is dead?
> >
> >
> > [5015721.851044] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action
> > 0x0 [5015721.851089] ata3.00: irq_stat 0x40000001
> > [5015721.851124] ata3.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
> > [5015721.851125]          res 71/04:03:80:01:32/00:00:00:00:00/e0 Emask
> > 0x1 (device error)
> > [5015721.851193] ata3.00: status: { DRDY DF ERR }
> > [5015721.851225] ata3.00: error: { ABRT }
> > [5015726.848684] ata3.00: qc timeout (cmd 0xec)
> > [5015726.848729] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x5)
> > [5015726.848763] ata3.00: revalidation failed (errno=-5)
> > [5015726.848798] ata3: hard resetting link
> > [5015734.501527] ata3: softreset failed (device not ready)
> > [5015734.501565] ata3: failed due to HW bug, retry pmp=0
> > [5015734.665530] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> > [5015734.707085] ata3.00: both IDENTIFYs aborted, assuming NODEV
> > [5015734.707089] ata3.00: revalidation failed (errno=-2)
> > [5015739.664923] ata3: hard resetting link
> > [5015740.148277] ata3: softreset failed (device not ready)
> > [5015740.148314] ata3: failed due to HW bug, retry pmp=0
> > [5015740.313532] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> > [5015740.337129] ata3.00: both IDENTIFYs aborted, assuming NODEV
(Continue reading)


Gmane