All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bokhan <aptem@ngs.ru>
To: "Bjørn Mork" <bjorn@mork.no>
Cc: linux-ide@vger.kernel.org
Subject: Re: kernel problems with smart on LSI-92xx
Date: Fri, 26 Nov 2010 21:42:21 +0600	[thread overview]
Message-ID: <4CEFD55D.8060200@ngs.ru> (raw)
In-Reply-To: <87y690hs3r.fsf@nemi.mork.no>

   It appears that passing self-test command to SATA disk does not work too. 
Although nobody reports any error, self-test actually just does not start.

smartctl -d megaraid,10 -t long /dev/sg0

smartctl 5.40 2010-10-16 r3189 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

/dev/sg0 [megaraid_disk_10] [SAT]: Device open changed type from 'megaraid' to 'sat'
=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Extended self-test routine immediately in 
off-line mode".
Drive command "Execute SMART Extended self-test routine immediately in off-line 
mode" successful.
Testing has begun.
Please wait 255 minutes for test to complete.
Test will complete after Sat Nov 27 01:54:44 2010

Use smartctl -X to abort test.


11.11.2010 20:06, Bjørn Mork пишет:
> Bokhan Artem<aptem@ngs.ru>  writes:
>
>> Hello.
>>
>> I have kernel problems when trying to run smart commands on LSI-92xx
>> controller.
>>
>> Running self-test  on SAS disk (smartctl /dev/sda -dmegaraid,24 -t
>> long) with smartmontools causes kernel oops (?) (and segfault). Look
>> in attachment for dmesg.
>>
>> strace of smartctl:
>>
>> mknod("/dev/megaraid_sas_ioctl_node", S_IFCHR, makedev(251, 0)) = -1 EEXIST
>> (File exists)
>> close(4)                                = 0
>> munmap(0x7f4be3a9f000, 4096)            = 0
>> open("/dev/megaraid_sas_ioctl_node", O_RDWR) = 4
>> ioctl(4, MTRRIOC_SET_ENTRY, 0x7fffa574ed30) = 0
>> ioctl(4, MTRRIOC_SET_ENTRY, 0x7fffa574eb30) = 0
>> ioctl(4, MTRRIOC_SET_ENTRY<unfinished ...>
>> +++ killed by SIGSEGV +++
>>
>>
>> Viewing  smart info is OK (smartctl /dev/sda -dmegaraid,24 -a).
>> Running self-test on SATA disk on the same system is OK.
>>
>> The problem is reproducible with 2.6.32 and 2.6.36 kernels.
> A quick look at this reveals that smartctl will happily do a
> MEGASAS_IOC_FIRMWARE ioctl with sge_count = 1 and sgl[0].iov_len = 0 if
> it is sending a command with dataLen == 0 :
>
>
> /* Issue passthrough scsi command to PERC5/6 controllers */
> bool linux_megaraid_device::megasas_cmd(int cdbLen, void *cdb,
>    int dataLen, void *data,
>    int /*senseLen*/, void * /*sense*/, int /*report*/)
> {
>    struct megasas_pthru_frame    *pthru;
>    struct megasas_iocpacket      uio;
>    struct megasas_iocpacket      uio;
>    int rc;
>
>    memset(&uio, 0, sizeof(uio));
>    pthru = (struct megasas_pthru_frame *)uio.frame.raw;
>    pthru->cmd = MFI_CMD_PD_SCSI_IO;
>    int rc;
>
>    memset(&uio, 0, sizeof(uio));
>    pthru = (struct megasas_pthru_frame *)uio.frame.raw;
>    pthru->cmd = MFI_CMD_PD_SCSI_IO;
>    pthru->cmd_status = 0xFF;
>    pthru->scsi_status = 0x0;
>    pthru->target_id = m_disknum;
>    pthru->lun = 0;
>    pthru->cdb_len = cdbLen;
>    pthru->timeout = 0;
>    pthru->flags = MFI_FRAME_DIR_READ;
>    pthru->sge_count = 1;
>    pthru->data_xfer_len = dataLen;
>    pthru->sgl.sge32[0].phys_addr = (intptr_t)data;
>    pthru->sgl.sge32[0].length = (uint32_t)dataLen;
>    memcpy(pthru->cdb, cdb, cdbLen);
>
>    uio.host_no = m_hba;
>    uio.sge_count = 1;
>    uio.sgl_off = offsetof(struct megasas_pthru_frame, sgl);
>    uio.sgl[0].iov_base = data;
>    uio.sgl[0].iov_len = dataLen;
>
>    rc = 0;
>    errno = 0;
>    rc = ioctl(m_fd, MEGASAS_IOC_FIRMWARE,&uio);
>    if (pthru->cmd_status || rc != 0) {
>      if (pthru->cmd_status == 12) {
>        return set_err(EIO, "megasas_cmd: Device %d does not exist\n", m_disknum);
>      }
>      return set_err((errno ? errno : EIO), "megasas_cmd result: %d.%d = %d/%d",
>                     m_hba, m_disknum, errno,
>                     pthru->cmd_status);
>    }
>    return true;
> }
>
>
>
> The kernel bug is that the zero valued sgl[0].iov_len is passed
> unmodified to megasas_mgmt_fw_ioctl() which again passes it on as size
> to dma_alloc_coherent():
>
>          /*
>           * For each user buffer, create a mirror buffer and copy in
>           */
>          for (i = 0; i<  ioc->sge_count; i++) {
>                  kbuff_arr[i] = dma_alloc_coherent(&instance->pdev->dev,
>                                                      ioc->sgl[i].iov_len,
>                                                      &buf_handle, GFP_KERNEL);
>
>
>
> And it looks like most (all?) of the dma_alloc_coherent()
> implementations will use get_order(size) to compute the necessary
> allocation. This will fail if size == 0.
>
> On the other hand, I may have misunderstood this entirely....
>
> But if you dare, you could try the attached patch (compile tested only
> as I don't have the hardware) and see if it helps.  Let me know how it
> goes, and I'll forward it to the megaraid manitainers if it really fixes
> your problem.
>
>
>
>
> Bjørn
>


  parent reply	other threads:[~2010-11-26 15:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-09 19:27 kernel problems with smart on LSI-92xx Bokhan Artem
2010-11-11 14:06 ` Bjørn Mork
2010-11-10 17:21   ` Bokhan Artem
2010-11-11 18:02     ` [PATCH] [SCSI] megaraid_sas: Sanity check user supplied length before passing it to dma_alloc_coherent() Bjørn Mork
2010-12-03 14:37       ` Bjørn Mork
2011-01-18 21:46         ` Bjørn Mork
     [not found]           ` <4B6A08C587958942AA3002690DD4F8C30106FA7846@cosmail02.lsi.com>
2011-01-19  6:33             ` Bjørn Mork
2011-01-19  8:12               ` FUJITA Tomonori
2011-01-19  8:56                 ` Bjørn Mork
2011-01-19  9:01                   ` [PATCH v3] " Bjørn Mork
2011-01-20  0:20               ` [PATCH] " Benz, Michael
2011-01-20  2:39                 ` FUJITA Tomonori
2010-11-26 15:42   ` Artem Bokhan [this message]
2010-11-29  7:09     ` kernel problems with smart on LSI-92xx Bjørn Mork
2010-11-29  9:49       ` Artem Bokhan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CEFD55D.8060200@ngs.ru \
    --to=aptem@ngs.ru \
    --cc=bjorn@mork.no \
    --cc=linux-ide@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.