smartctl / mpt on 9.0-RC1

Frank Razenberg frank at zzattack.org
Wed Nov 2 23:50:09 UTC 2011


Thanks for your reply. It seems I'm missing a lot of debug symbols. I 
will look into getting a more useful backtrace.
For what it's worth I added the gdb output below.

-Frank

    # gdb /usr/local/sbin/smartctl ~/smartctl.core
    GNU gdb 6.1.1 [FreeBSD]
    Copyright 2004 Free Software Foundation, Inc.
    GDB is free software, covered by the GNU General Public License, and
    you are
    welcome to change it and/or distribute copies of it under certain
    conditions.
    Type "show copying" to see the conditions.
    There is absolutely no warranty for GDB.  Type "show warranty" for
    details.
    This GDB was configured as "amd64-marcel-freebsd"...(no debugging
    symbols found)...
    Core was generated by `smartctl'.
    Program terminated with signal 11, Segmentation fault.
    Reading symbols from /lib/libcam.so.6...(no debugging symbols
    found)...done.
    Loaded symbols for /lib/libcam.so.6
    Reading symbols from /usr/lib/libusb.so.2...(no debugging symbols
    found)...done.
    Loaded symbols for /usr/lib/libusb.so.2
    Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols
    found)...done.
    Loaded symbols for /usr/lib/libstdc++.so.6
    Reading symbols from /lib/libm.so.5...(no debugging symbols
    found)...done.
    Loaded symbols for /lib/libm.so.5
    Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols
    found)...done.
    Loaded symbols for /lib/libgcc_s.so.1
    Reading symbols from /lib/libc.so.7...(no debugging symbols
    found)...done.
    Loaded symbols for /lib/libc.so.7
    Reading symbols from /lib/libsbuf.so.6...(no debugging symbols
    found)...done.
    Loaded symbols for /lib/libsbuf.so.6
    Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols
    found)...done.
    Loaded symbols for /libexec/ld-elf.so.1
    #0  0x0000000000000000 in ?? ()
    (gdb) bt
    #0  0x0000000000000000 in ?? ()
    #1  0x0000000000000000 in ?? ()
    #2  0x0000000000000000 in ?? ()
    #3  0x0000000000000000 in ?? ()
    #4  0x0000000000000000 in ?? ()
    #5  0x0000000000000000 in ?? ()
    #6  0x0000000000000000 in ?? ()
    #7  0x0000000000000000 in ?? ()
    #8  0x0000000000000000 in ?? ()
    #9  0x0000000000000000 in ?? ()
    #10 0x0000000000000000 in ?? ()
    #11 0x0000000000000000 in ?? ()
    #12 0x0000000000000000 in ?? ()
    #13 0x0000000000000000 in ?? ()
    #14 0x0000000000000000 in ?? ()
    #15 0x0000000000000000 in ?? ()
    #16 0x0000000000000000 in ?? ()
    #17 0x0000000000000000 in ?? ()
    #18 0x0000000000000000 in ?? ()
    #19 0x0000000000000000 in ?? ()
    #20 0x0000000000000000 in ?? ()
    #21 0x0000000000000000 in ?? ()
    #22 0x0000000000000000 in ?? ()
    #23 0x0000000000000000 in ?? ()
    #24 0x0000000000000000 in ?? ()
    #25 0x0000000000000000 in ?? ()
    #26 0x0000000000000000 in ?? ()
    #27 0xffffffff00000000 in ?? ()
    #28 0x0000000000000000 in ?? ()
    #29 0x0000000000000000 in ?? ()
    #30 0x0000000000000000 in ?? ()
    #31 0x0000000000000000 in ?? ()
    #32 0x0000000000000000 in ?? ()
    #33 0x0000000000000000 in ?? ()
    #34 0x0000000000000000 in ?? ()
    ---Type <return> to continue, or q <return> to quit---



On 11/3/2011 12:38 AM, Jeremy Chadwick wrote:
> On Wed, Nov 02, 2011 at 10:57:01PM +0100, Frank Razenberg wrote:
>> Ever since I tried 9.0-RC1 I haven't been able to read SMART values
>> of the disks attached to my Intel SASUC8i (LSI 1068e rebrand)
>> controller with smartctl. Similar disks on motherboard SATA ports
>> can be queried as expected.
>>
>>     # smartctl -a /dev/da0
>>     smartctl 5.42 2011-10-20 r3458 [FreeBSD 9.0-RC1 amd64] (local build)
>>     Copyright (C) 2002-11 by Bruce Allen,
>>     http://smartmontools.sourceforge.net
>>
>>     Segmentation fault (core dumped)
>>
>> The controller was flashed to run in IT-mode. The relevant
>> smartctl.core dump is available at
>> http://files.zzattack.org/smartctl.core.zip
>>
>> Suggestions or a fix would be highly appreciated.
> You will need to debug the core yourself, not provide it to us.
> Sometimes cores are specific to a person's system.
>
> Please run "gdb /usr/local/sbin/smartctl smartctl.core" and provide here
> the function call stack.  This will help determine if it's a bug in
> smartctl or something FreeBSD-related.  If it's a smartmontools problem,
> you will need to report the bug to them directly via Sourceforge.
>



More information about the freebsd-stable mailing list