Re: smartctl / mpt on 9.0-RC1

2011-11-09 Thread Marat N.Afanasyev

Alex Samorukov wrote:

On 11/08/2011 09:33 PM, Marat N.Afanasyev wrote:

why :)

just a little misunderstanding, I suppose ;) I just showed what I'd
expect from

#smartctl -a -d 3ware,0 /dev/twa0

in case of sas drive on channel 0

Yes.

BTW, if you able to provide access to the BSD box with MFI and SAS i
could fix "defect sectors" status report. For the twa/SAS much work
needs to be done, but if there is anyone with such controller and
hardware (not in production!) i could try, at least.


I have one of my boxes  being repaired, so as soon as it will be 
returned I'll try to give you access to that box. Unfortunately all my 
sas drives attached to 3ware controllers are in production boxes, so 
playing with them are not possible :(


--
SY, Marat



Re: smartctl / mpt on 9.0-RC1

2011-11-09 Thread Alex Samorukov

On 11/08/2011 09:33 PM, Marat N.Afanasyev wrote:

why :)

just a little misunderstanding, I suppose ;) I just showed what I'd 
expect from


#smartctl -a -d 3ware,0 /dev/twa0

in case of sas drive on channel 0

Yes.

BTW, if you able to provide access to the BSD box with MFI and SAS i 
could fix "defect sectors" status report. For the twa/SAS much work 
needs to be done, but if there is anyone with such controller and 
hardware (not in production!) i could try, at least.


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: smartctl / mpt on 9.0-RC1

2011-11-08 Thread Marat N.Afanasyev

Alex Samorukov wrote:

On 11/07/2011 03:10 PM, Jeremy Chadwick wrote:

I see. I wasn't aware there was an ioctl(2) interface to twa(4).

This makes me wonder: why does Marat use /dev/passX as his device when
using smartctl?

Because Marat using LSI mfi (not 3ware twa!) driver in this case.
mfip.ko exports /dev/passX devices for every disk in the raid.

Could this have some bearing on why he doesn't see the
necessary data returned from (if even submit to) the underlying disk?
The syntax of his command was: "smartctl -a /dev/pass1". I would have
expected the syntax to be "smartctl -a -d 3ware,1 /dev/twa".

What I'm trying to get at here is whether or not smartmontools "does the
right thing" in this situation. Does the output differ between the
above two syntaxes? I don't see any mention in twa(4)'s man page that
pass(4) is even registered/used -- though I do see it mentioned that CAM
is used by twa(4).

Smartmontools will not work on twa with SAS drives, because it is using
IOCTL packet format for the ATA protocol. And we need to use SCSI
packets to speak with SAS devices. This code is currently not written.


Furthermore, later comments below indicate CAM isn't involved, which
further confuses me. Can someone help relieve my confusion on this
matter?

Because Marat provided output for another controller and another driver.
For me it is also unclear why :)


just a little misunderstanding, I suppose ;) I just showed what I'd 
expect from


#smartctl -a -d 3ware,0 /dev/twa0

in case of sas drive on channel 0

--
SY, Marat



Re: smartctl / mpt on 9.0-RC1

2011-11-07 Thread Alex Samorukov

On 11/07/2011 03:10 PM, Jeremy Chadwick wrote:

I see.  I wasn't aware there was an ioctl(2) interface to twa(4).

This makes me wonder: why does Marat use /dev/passX as his device when
using smartctl?
Because Marat using LSI mfi (not 3ware twa!) driver in this case. 
mfip.ko exports /dev/passX devices for every disk in the raid.

  Could this have some bearing on why he doesn't see the
necessary data returned from (if even submit to) the underlying disk?
The syntax of his command was: "smartctl -a /dev/pass1".  I would have
expected the syntax to be "smartctl -a -d 3ware,1 /dev/twa".

What I'm trying to get at here is whether or not smartmontools "does the
right thing" in this situation.  Does the output differ between the
above two syntaxes?  I don't see any mention in twa(4)'s man page that
pass(4) is even registered/used -- though I do see it mentioned that CAM
is used by twa(4).
Smartmontools will not work on twa with SAS drives, because it is using 
IOCTL packet format for the ATA protocol. And we need to use SCSI 
packets to speak with SAS devices. This code is currently not written.


Furthermore, later comments below indicate CAM isn't involved, which
further confuses me.  Can someone help relieve my confusion on this
matter?
Because Marat provided output for another controller and another driver. 
For me it is also unclear why :)


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: smartctl / mpt on 9.0-RC1

2011-11-07 Thread Jeremy Chadwick
On Mon, Nov 07, 2011 at 02:17:21PM +0100, Alex Samorukov wrote:
> On 11/07/2011 02:06 PM, Jeremy Chadwick wrote:
> >On Mon, Nov 07, 2011 at 04:53:36PM +0400, Marat N.Afanasyev wrote:
> btw, 3dm can tell about reallocated sector count on sas somehow,
> while smartctl cannot, even on supported controller :(
> >>>I think this is getting into a separate discussion topic.
> >>>
> >>>I realise we're discussing SAS, but what's shown above looks pure and
> >>>total SCSI output from smartmontools.  I'm very familiar with it (we
> >>>predominantly used SCSI disks at my workplace up until ~1 year ago).
> >>>
> >>I will be satisfied with scsi-like output of smartctl for my sas
> >>drive on twa controller ;)
> >Did you actually look at the output I provided?  It's more or less the
> >same, minus data which you want that isn't being shown (at all).  That
> >includes things like drive manufacturing date, etc..
> >
> >The problem could be in one of the following layers:
> >
> >1. smartmontools itself
> Hi Jeremy,
> 
> It is "smartmontools itself" problem. On twa (3ware devices) we are
> using ATA-type of packets to speak with the device. It is fine for
> ATA/SATA disks, but not for SATA, which are using SCSI commands. The
> code for the SCSI conversation just needs to be written (btw, the
> same on Linux). Driver itself provides TWA_FW_CMD_EXECUTE_SCSI type
> of the packet, so it probably (!) possible to speak with underlying
> disks using it, but it needs to be tested. The problem is that i
> have no such controllers or drives. I could try to add this
> functionality if anyone will provide me access, but it should not be
> production system with any important data. E.g. when i was working
> on LSI code i had array degradations and controller hangs on
> legitimate SAT commands.

I see.  I wasn't aware there was an ioctl(2) interface to twa(4).

This makes me wonder: why does Marat use /dev/passX as his device when
using smartctl?  Could this have some bearing on why he doesn't see the
necessary data returned from (if even submit to) the underlying disk?
The syntax of his command was: "smartctl -a /dev/pass1".  I would have
expected the syntax to be "smartctl -a -d 3ware,1 /dev/twa".

What I'm trying to get at here is whether or not smartmontools "does the
right thing" in this situation.  Does the output differ between the
above two syntaxes?  I don't see any mention in twa(4)'s man page that
pass(4) is even registered/used -- though I do see it mentioned that CAM
is used by twa(4).

Furthermore, later comments below indicate CAM isn't involved, which
further confuses me.  Can someone help relieve my confusion on this
matter?

> >2. CAM translation layer (e.g. pass(4) or related bits)
> >3. twa(4) driver
>
> 2. is not in use, smartmontools using ioctl api to send commands to
> firmware. 3. - under the question.
>
> >4. 3Ware controller firmware
>
> 4. Yes, needs to be tested. It is common to see bugs in firmware in
> this area, it is not usually well tested (LSI with SAT protocol is a
> good example, i did workaround for this in recent smartmontools
> update).
>
> >It is possible to determine if #1 and #2 are responsible by enabling
> >CAMDEBUG and/or using "camcontrol debug" to watch all CDBs which are
> >submit to the controller.  I'm not sure which one is responsible for
> >obtaining defect counts and so on -- I would need to review SAS and/or
> >SCSI specifications.  The information should be available per
> >T10's SCSI and SAS specification documents.
> >
> >An alternate way to check would be to boot into a Linux LiveCD and
> >install smartmontools (in RAM) and see if it provides the data.
>
> It would not. Just because SCSI interface for this driver is not
> implemented.
>
> >My point: don't be so quick to assume smartmontools is responsible when
> >there are 4 (maybe even 5) "layers" to how SCSI I/O makes it to the
> >actual drive.  This is one of the many reasons I try to avoid hardware
> >RAID controllers -- too much crap between me and the device I wish to
> >speak to.
>
> Its controversy statement. From my own point of view - device
> authors should implement passX devices for the disks like it done on
> mfip.ko or with Adaptec (at least on Linux).

Yes, agreed.  But there are also some cards which register with pass(4)
but don't pass raw CDBs to the disk spoken to -- meaning, the firmware
itself is actually mangling/filtering CDBs.  So even though it's a
matter of opinion/controversy, the fact of the matter is that with these
types of cards cards (not picking on 3Ware here specifically), there are
so many layers of abstraction that figuring out which piece (meaning
which item of the above 4 items I provided) is responsible is very
difficult.  From the end-user perspective, it's as simple as "it doesn't
work"; from the developer's perspective, it's time-consuming and
annoying.

-- 
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking   http://ww

Re: mfip and smartctl Re: smartctl / mpt on 9.0-RC1

2011-11-07 Thread Alex Samorukov

On 11/07/2011 02:47 PM, Andrew Boyer wrote:


[GLTSD (Global Logging Target Save Disable) set. Enable Save with '-S on']
No self-tests have been logged
Long (extended) Self Test duration: 1740 seconds [29.0 minutes]

btw, 3dm can tell about reallocated sector count on sas somehow, while smartctl 
cannot, even on supported controller :(
Notice how the device type is "<31>"?  The mfip driver masks off the SCSI 
INQUIRY peripheral device type bits to prevent CAM from attached da* devices to the disks.  See 
sys/dev/mfi/mfi_cam.c, search for T_DIRECT.  That confuses smartctl and prevents it from 
displaying information like the Grown Defect List.

I added a local hack to smartctl to interpret a peripheral device type of 0x1f 
(unknown or missing) to 0x0 (disk), but I don't think the hack is appropriate 
for general consumption.  What we need is better way for mfi and aac to block 
CAM from attaching without corrupting the inquiry results
I can add hack to the sources with checking if underlying driver is mfi 
(there are already some for buggy SAT fw implementation). It is probably 
easiest way to do this. I just tested - firmware itself returns correct 
(disk) status.


Of course in the feature its better to fix in mfi_cam to avoid such hacks.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


mfip and smartctl Re: smartctl / mpt on 9.0-RC1

2011-11-07 Thread Andrew Boyer
On Nov 7, 2011, at 6:24 AM, Marat N.Afanasyev wrote:
> 
> this is an output on mfi controller with mfip loaded:
> 
> # smartctl -a /dev/pass1
> smartctl 5.41 2011-06-09 r3365 [FreeBSD 8.2-RELEASE amd64] (local build)
> Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net
> 
> Vendor:   SEAGATE
> Product:  ST3146356SS
> Revision: 0007
> User Capacity:146,815,737,856 bytes [146 GB]
> Logical block size:   512 bytes
> Logical Unit id:  0x5000c50028f8a56f
> Serial number:3QN4PWHS9130JLKB
> Device type:  <31>
> Transport protocol:   SAS
> Local Time is:Mon Nov  7 15:20:27 2011 MSK
> Device supports SMART and is Enabled
> Temperature Warning Enabled
> SMART Health Status: OK
> 
> Current Drive Temperature: 26 C
> Drive Trip Temperature:68 C
> 
> Error counter log:
>   Errors Corrected by   Total   Correction GigabytesTotal
>   ECC  rereads/errors   algorithm processed
> uncorrected
>   fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  
> errors
> read:93821240 0   93821249382124   3436.782   
> 0
> write: 00 0 0  0   8978.360   
> 0
> verify:   6634330 0663433 663433332.651   
> 0
> 
> Non-medium error count:7
> 
> [GLTSD (Global Logging Target Save Disable) set. Enable Save with '-S on']
> No self-tests have been logged
> Long (extended) Self Test duration: 1740 seconds [29.0 minutes]
> 
> btw, 3dm can tell about reallocated sector count on sas somehow, while 
> smartctl cannot, even on supported controller :(

Notice how the device type is "<31>"?  The mfip driver masks off the SCSI 
INQUIRY peripheral device type bits to prevent CAM from attached da* devices to 
the disks.  See sys/dev/mfi/mfi_cam.c, search for T_DIRECT.  That confuses 
smartctl and prevents it from displaying information like the Grown Defect List.

I added a local hack to smartctl to interpret a peripheral device type of 0x1f 
(unknown or missing) to 0x0 (disk), but I don't think the hack is appropriate 
for general consumption.  What we need is better way for mfi and aac to block 
CAM from attaching without corrupting the inquiry results.

-Andrew

> -- 
> SY, Marat
> 

--
Andrew Boyerabo...@averesystems.com




___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: smartctl / mpt on 9.0-RC1

2011-11-07 Thread Alex Samorukov

On 11/07/2011 02:06 PM, Jeremy Chadwick wrote:

On Mon, Nov 07, 2011 at 04:53:36PM +0400, Marat N.Afanasyev wrote:

btw, 3dm can tell about reallocated sector count on sas somehow,
while smartctl cannot, even on supported controller :(

I think this is getting into a separate discussion topic.

I realise we're discussing SAS, but what's shown above looks pure and
total SCSI output from smartmontools.  I'm very familiar with it (we
predominantly used SCSI disks at my workplace up until ~1 year ago).


I will be satisfied with scsi-like output of smartctl for my sas
drive on twa controller ;)

Did you actually look at the output I provided?  It's more or less the
same, minus data which you want that isn't being shown (at all).  That
includes things like drive manufacturing date, etc..

The problem could be in one of the following layers:

1. smartmontools itself

Hi Jeremy,

It is "smartmontools itself" problem. On twa (3ware devices) we are 
using ATA-type of packets to speak with the device. It is fine for 
ATA/SATA disks, but not for SATA, which are using SCSI commands. The 
code for the SCSI conversation just needs to be written (btw, the same 
on Linux). Driver itself provides TWA_FW_CMD_EXECUTE_SCSI type of the 
packet, so it probably (!) possible to speak with underlying disks using 
it, but it needs to be tested. The problem is that i have no such 
controllers or drives. I could try to add this functionality if anyone 
will provide me access, but it should not be production system with any 
important data. E.g. when i was working on LSI code i had array 
degradations and controller hangs on legitimate SAT commands.



2. CAM translation layer (e.g. pass(4) or related bits)
3. twa(4) driver
2. is not in use, smartmontools using ioctl api to send commands to 
firmware. 3. - under the question.

4. 3Ware controller firmware
4. Yes, needs to be tested. It is common to see bugs in firmware in this 
area, it is not usually well tested (LSI with SAT protocol is a good 
example, i did workaround for this in recent smartmontools update).


It is possible to determine if #1 and #2 are responsible by enabling
CAMDEBUG and/or using "camcontrol debug" to watch all CDBs which are
submit to the controller.  I'm not sure which one is responsible for
obtaining defect counts and so on -- I would need to review SAS and/or
SCSI specifications.  The information should be available per
T10's SCSI and SAS specification documents.

An alternate way to check would be to boot into a Linux LiveCD and
install smartmontools (in RAM) and see if it provides the data.
It would not. Just because SCSI interface for this driver is not 
implemented.


My point: don't be so quick to assume smartmontools is responsible when
there are 4 (maybe even 5) "layers" to how SCSI I/O makes it to the
actual drive.  This is one of the many reasons I try to avoid hardware
RAID controllers -- too much crap between me and the device I wish to
speak to.
Its controversy statement. From my own point of view - device authors 
should implement passX devices for the disks like it done on mfip.ko or 
with Adaptec (at least on Linux).


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: smartctl / mpt on 9.0-RC1

2011-11-07 Thread Jeremy Chadwick
On Mon, Nov 07, 2011 at 04:53:36PM +0400, Marat N.Afanasyev wrote:
> >>btw, 3dm can tell about reallocated sector count on sas somehow,
> >>while smartctl cannot, even on supported controller :(
> >
> >I think this is getting into a separate discussion topic.
> >
> >I realise we're discussing SAS, but what's shown above looks pure and
> >total SCSI output from smartmontools.  I'm very familiar with it (we
> >predominantly used SCSI disks at my workplace up until ~1 year ago).
> >
> 
> I will be satisfied with scsi-like output of smartctl for my sas
> drive on twa controller ;)

Did you actually look at the output I provided?  It's more or less the
same, minus data which you want that isn't being shown (at all).  That
includes things like drive manufacturing date, etc..

The problem could be in one of the following layers:

1. smartmontools itself
2. CAM translation layer (e.g. pass(4) or related bits)
3. twa(4) driver
4. 3Ware controller firmware

It is possible to determine if #1 and #2 are responsible by enabling
CAMDEBUG and/or using "camcontrol debug" to watch all CDBs which are
submit to the controller.  I'm not sure which one is responsible for
obtaining defect counts and so on -- I would need to review SAS and/or
SCSI specifications.  The information should be available per
T10's SCSI and SAS specification documents.

An alternate way to check would be to boot into a Linux LiveCD and
install smartmontools (in RAM) and see if it provides the data.

My point: don't be so quick to assume smartmontools is responsible when
there are 4 (maybe even 5) "layers" to how SCSI I/O makes it to the
actual drive.  This is one of the many reasons I try to avoid hardware
RAID controllers -- too much crap between me and the device I wish to
speak to.

-- 
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator   Mountain View, CA, US |
| Making life hard for others since 1977.   PGP 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: smartctl / mpt on 9.0-RC1

2011-11-07 Thread Marat N.Afanasyev

btw, 3dm can tell about reallocated sector count on sas somehow,
while smartctl cannot, even on supported controller :(


I think this is getting into a separate discussion topic.

I realise we're discussing SAS, but what's shown above looks pure and
total SCSI output from smartmontools.  I'm very familiar with it (we
predominantly used SCSI disks at my workplace up until ~1 year ago).



I will be satisfied with scsi-like output of smartctl for my sas drive 
on twa controller ;)


--
SY, Marat



Re: smartctl / mpt on 9.0-RC1

2011-11-07 Thread Jeremy Chadwick
On Mon, Nov 07, 2011 at 03:24:03PM +0400, Marat N.Afanasyev wrote:
> Alex Samorukov wrote:
> >On 11/06/2011 09:37 PM, Alex Samorukov wrote:
> >>>Command failed, ata.status=(0x00), ata.command=(0xec), ata.flags=(0x01)
> >>>WARNING - NO DEVICE FOUND ON 3WARE CONTROLLER (disk 0)
> >>>Smartctl: Device Read Identity Failed (not an ATA/ATAPI device)
> >>>
> >>>A mandatory SMART command failed: exiting. To continue, add one or
> >>>more '-T permissive' options.
> >>>
> >>
> >>
> >>Ok, looking in the code i found that on "3ware" device only
> >>"ata_command_interface" is implemented (with
> >>TW_OSL_IOCTL_FIRMWARE_PASS_THROUGH). The question is if that interface
> >>actually supports SAS drives at all. From the quick view of the
> >>sources i found TWE_Command_ATA packet description, but nothing
> >>related to SCSI/SATA packets. So i am not sure that it is possible at
> >>all. If you know any tool which able to get health information for SAS
> >>drives we can try to debug ioctl it using to find the way to talk with
> >>disk.
> >>
> >One more update - there is TWA_FW_CMD_EXECUTE_SCSI command in the twa
> >driver, so it should be possible to get required data. I have no access
> >to such hardware, but if anyone if going to provide it - i could try at
> >least.
> >
> this is an output on mfi controller with mfip loaded:
> 
> # smartctl -a /dev/pass1
> smartctl 5.41 2011-06-09 r3365 [FreeBSD 8.2-RELEASE amd64] (local build)
> Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net
> 
> Vendor:   SEAGATE
> Product:  ST3146356SS
> Revision: 0007
> User Capacity:146,815,737,856 bytes [146 GB]
> Logical block size:   512 bytes
> Logical Unit id:  0x5000c50028f8a56f
> Serial number:3QN4PWHS9130JLKB
> Device type:  <31>
> Transport protocol:   SAS
> Local Time is:Mon Nov  7 15:20:27 2011 MSK
> Device supports SMART and is Enabled
> Temperature Warning Enabled
> SMART Health Status: OK
> 
> Current Drive Temperature: 26 C
> Drive Trip Temperature:68 C
> 
> Error counter log:
>Errors Corrected by   Total   Correction
> GigabytesTotal
>ECC  rereads/errors   algorithm processed
> uncorrected
>fast | delayed   rewrites  corrected  invocations   [10^9
> bytes]  errors
> read:93821240 0   93821249382124
> 3436.782   0
> write: 00 0 0  0
> 8978.360   0
> verify:   6634330 0663433 663433
> 332.651   0
> 
> Non-medium error count:7
> 
> [GLTSD (Global Logging Target Save Disable) set. Enable Save with '-S on']
> No self-tests have been logged
> Long (extended) Self Test duration: 1740 seconds [29.0 minutes]
> 
> btw, 3dm can tell about reallocated sector count on sas somehow,
> while smartctl cannot, even on supported controller :(

I think this is getting into a separate discussion topic.

I realise we're discussing SAS, but what's shown above looks pure and
total SCSI output from smartmontools.  I'm very familiar with it (we
predominantly used SCSI disks at my workplace up until ~1 year ago).

SCSI disks only support two kinds of "reallocations": grown defects and
physical defects.  Physical defects are "factory-known bad sectors"
while grown defects are ones learned over time.  Both defect lists are
manageable via SCSI CDBs (meaning you can literally tell the disk "make
LBA N considered a grown defect").  Furthermore, an actual low-level
format will in effect "merge" the grown defect list into the physical
defect list (e.g. prior to format, physical defect list = 225 sectors,
grown = 10; after format, physical = 235, grown = 0).  The defect lists
are also viewable.

smartmontools does support display of both defect counts.  So, either
SAS support in smartmontools lacks code for getting this, SAS (because
it's SAS) does something different, or the controller itself (or
pass(4)) is intercepting the response data.  I simply do not know
because I have no experience with SAS.  I really don't know what people
are expecting, SMART-wise, with SAS.  To me, the above output looks
perfectly normal sans some details and defect counts.

Proof of my statements, re: smartmontools on SCSI disks (taken from a
Solaris 10 system):

# smartctl -a /dev/rdsk/c0t0d0s0
smartctl 5.40 2010-10-16 r3189 [i386-pc-solaris2.10] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

Device: FUJITSU  MAW3073NCVersion: 0104
Serial number: DAL0P6802E1Y
Device type: disk
Transport protocol: Parallel SCSI (SPI-4)
Local Time is: Mon Nov  7 03:38:52 2011 PST
Device supports SMART and is Enabled
Temperature Warning Enabled
SMART Health Status: OK

Current Drive Temperature: 26 C
Drive Trip Temperature:65 C
Manufactured in week 31 of year 2006
Specified cycle count over device lifetime:  1
Accumulated start-stop cycles:  10
Ele

Re: smartctl / mpt on 9.0-RC1

2011-11-07 Thread Marat N.Afanasyev

Alex Samorukov wrote:

On 11/06/2011 09:37 PM, Alex Samorukov wrote:

Command failed, ata.status=(0x00), ata.command=(0xec), ata.flags=(0x01)
WARNING - NO DEVICE FOUND ON 3WARE CONTROLLER (disk 0)
Smartctl: Device Read Identity Failed (not an ATA/ATAPI device)

A mandatory SMART command failed: exiting. To continue, add one or
more '-T permissive' options.




Ok, looking in the code i found that on "3ware" device only
"ata_command_interface" is implemented (with
TW_OSL_IOCTL_FIRMWARE_PASS_THROUGH). The question is if that interface
actually supports SAS drives at all. From the quick view of the
sources i found TWE_Command_ATA packet description, but nothing
related to SCSI/SATA packets. So i am not sure that it is possible at
all. If you know any tool which able to get health information for SAS
drives we can try to debug ioctl it using to find the way to talk with
disk.


One more update - there is TWA_FW_CMD_EXECUTE_SCSI command in the twa
driver, so it should be possible to get required data. I have no access
to such hardware, but if anyone if going to provide it - i could try at
least.


this is an output on mfi controller with mfip loaded:

# smartctl -a /dev/pass1
smartctl 5.41 2011-06-09 r3365 [FreeBSD 8.2-RELEASE amd64] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

Vendor:   SEAGATE
Product:  ST3146356SS
Revision: 0007
User Capacity:146,815,737,856 bytes [146 GB]
Logical block size:   512 bytes
Logical Unit id:  0x5000c50028f8a56f
Serial number:3QN4PWHS9130JLKB
Device type:  <31>
Transport protocol:   SAS
Local Time is:Mon Nov  7 15:20:27 2011 MSK
Device supports SMART and is Enabled
Temperature Warning Enabled
SMART Health Status: OK

Current Drive Temperature: 26 C
Drive Trip Temperature:68 C

Error counter log:
   Errors Corrected by   Total   Correction 
GigabytesTotal
   ECC  rereads/errors   algorithm 
processeduncorrected
   fast | delayed   rewrites  corrected  invocations   [10^9 
bytes]  errors
read:93821240 0   93821249382124   3436.782 
  0
write: 00 0 0  0   8978.360 
  0
verify:   6634330 0663433 663433332.651 
  0


Non-medium error count:7

[GLTSD (Global Logging Target Save Disable) set. Enable Save with '-S on']
No self-tests have been logged
Long (extended) Self Test duration: 1740 seconds [29.0 minutes]

btw, 3dm can tell about reallocated sector count on sas somehow, while 
smartctl cannot, even on supported controller :(


--
SY, Marat



Re: smartctl / mpt on 9.0-RC1

2011-11-06 Thread Alex Samorukov

On 11/06/2011 09:37 PM, Alex Samorukov wrote:

Command failed, ata.status=(0x00), ata.command=(0xec), ata.flags=(0x01)
WARNING - NO DEVICE FOUND ON 3WARE CONTROLLER (disk 0)
Smartctl: Device Read Identity Failed (not an ATA/ATAPI device)

A mandatory SMART command failed: exiting. To continue, add one or 
more '-T permissive' options.





Ok, looking in the code i found that on "3ware" device only 
"ata_command_interface" is implemented (with 
TW_OSL_IOCTL_FIRMWARE_PASS_THROUGH). The question is if that interface 
actually supports SAS drives at all. From the quick view of the 
sources i found  TWE_Command_ATA packet description, but nothing 
related to SCSI/SATA packets. So i am not sure that it is possible at 
all. If you know any tool which able to get health information for SAS 
drives we can try to debug ioctl it using to find the way to talk with 
disk.


One more update - there is TWA_FW_CMD_EXECUTE_SCSI command in the twa 
driver, so it should be possible to get required data. I have no access 
to such hardware, but if anyone if going to provide it - i could try at 
least.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: smartctl / mpt on 9.0-RC1

2011-11-06 Thread Alex Samorukov





it doesn't work :( sata drives are accessible, but for sas all we have:

# smartctl -d 3ware,0 -a /dev/twa0
smartctl 5.40 2010-10-16 r3189 [FreeBSD 8.2-RELEASE amd64] (local build)
Copyright (C) 2002-10 by Bruce Allen, 
http://smartmontools.sourceforge.net


Command failed, ata.status=(0x00), ata.command=(0xec), ata.flags=(0x01)
WARNING - NO DEVICE FOUND ON 3WARE CONTROLLER (disk 0)
Smartctl: Device Read Identity Failed (not an ATA/ATAPI device)

A mandatory SMART command failed: exiting. To continue, add one or 
more '-T permissive' options.




Ok, looking in the code i found that on "3ware" device only 
"ata_command_interface" is implemented (with 
TW_OSL_IOCTL_FIRMWARE_PASS_THROUGH). The question is if that interface 
actually supports SAS drives at all. From the quick view of the sources 
i found  TWE_Command_ATA packet description, but nothing related to 
SCSI/SATA packets. So i am not sure that it is possible at all. If you 
know any tool which able to get health information for SAS drives we can 
try to debug ioctl it using to find the way to talk with disk.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: smartctl / mpt on 9.0-RC1

2011-11-06 Thread Marat N.Afanasyev

Alex Samorukov wrote:

On 11/06/2011 04:52 PM, Marat N.Afanasyev wrote:



I wonder is there a possibility to monitor sas drives on twa controllers?

Hi Marat,

I have no access to such hardware so don`t know if it works or not.



it doesn't work :( sata drives are accessible, but for sas all we have:

# smartctl -d 3ware,0 -a /dev/twa0
smartctl 5.40 2010-10-16 r3189 [FreeBSD 8.2-RELEASE amd64] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

Command failed, ata.status=(0x00), ata.command=(0xec), ata.flags=(0x01)
WARNING - NO DEVICE FOUND ON 3WARE CONTROLLER (disk 0)
Smartctl: Device Read Identity Failed (not an ATA/ATAPI device)

A mandatory SMART command failed: exiting. To continue, add one or more 
'-T permissive' options.


--
С уважением, Марат Афанасьев



Re: smartctl / mpt on 9.0-RC1

2011-11-06 Thread Alex Samorukov

On 11/06/2011 04:52 PM, Marat N.Afanasyev wrote:



I wonder is there a possibility to monitor sas drives on twa controllers?

Hi Marat,

I have no access to such hardware so don`t know if it works or not.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: smartctl / mpt on 9.0-RC1

2011-11-06 Thread Marat N.Afanasyev

Alex Samorukov wrote:

On 11/03/2011 09:35 PM, James wrote:

Thanks, Alex. Looks like you fixed it. smartctl no longer segfaults.

Thank you for testing. I submitter PR [1] with this patch. It also
contain patch to avoid problems with SATA drives on LSI (SAS) controllers.

[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=162276

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Hi, Alex!

I wonder is there a possibility to monitor sas drives on twa controllers?

--
SY, Marat



Re: [smartmontools-support] smartctl / mpt on 9.0-RC1

2011-11-06 Thread Alex Samorukov
This is fixed by me in SVN. Also fix already applied in the ports, so 
please update your smartmontools port.


On 11/02/2011 10:57 PM, 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




___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: smartctl / mpt on 9.0-RC1

2011-11-03 Thread Mike Andrews

On 11/3/2011 4:09 PM, Alex Samorukov wrote:

On 11/03/2011 08:37 PM, James wrote:

On Thu, Nov 3, 2011 at 1:52 PM, Alex Samorukov  wrote:

Thank you. I currently got shell, but user-only, what is useless for
me ;-) (All ioctl/cam commands require superuser)

I asked for the root and now waiting for it. You can also provide
shell so i will have more boxes to test. I am expecting some very
trivial bug caused by some wrong data returned from the driver
without strict check in smartctl.

 No problem. Send me your public key privately and I'll set you up.

Could you please try to build latest svn version (see [1]) ? I think i 
fixed this bug.


The version that was just committed to the ports tree fixed my problem, 
fyi :)


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: smartctl / mpt on 9.0-RC1

2011-11-03 Thread Jeremy Chadwick
On Thu, Nov 03, 2011 at 03:35:48PM -0500, James wrote:
> On Thu, Nov 3, 2011 at 3:09 PM, Alex Samorukov  wrote:
> > Could you please try to build latest svn version (see [1]) ? I think
> > i fixed this bug.
> 
> Thanks, Alex. Looks like you fixed it. smartctl no longer
> segfaults.

I'm glad this patch fixes things for people, but does anyone have
insights to why the calling stack gets horribly corrupted on a segfault,
even with WITH_DEBUG (no optimisations and uses -g)?  It makes
troubleshooting this kind of problem extremely difficult.

-- 
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator   Mountain View, CA, US |
| Making life hard for others since 1977.   PGP 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: smartctl / mpt on 9.0-RC1

2011-11-03 Thread Alex Samorukov

On 11/03/2011 09:35 PM, James wrote:
Thanks, Alex. Looks like you fixed it. smartctl no longer segfaults. 
Thank you for testing. I submitter PR [1] with this patch. It also 
contain patch to avoid problems with SATA drives on LSI (SAS) controllers.


[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=162276

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: smartctl / mpt on 9.0-RC1

2011-11-03 Thread James
On Thu, Nov 3, 2011 at 3:09 PM, Alex Samorukov  wrote:
> Could you please try to build latest svn version (see [1]) ? I think
> i fixed this bug.

Thanks, Alex. Looks like you fixed it. smartctl no longer
segfaults.

-- 
James.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: smartctl / mpt on 9.0-RC1

2011-11-03 Thread Frank Razenberg
Thank you Alex, as you already confirmed, it works perfectly on my box
again. Thanks again.

-Frank

On Thu, Nov 3, 2011 at 9:09 PM, Alex Samorukov  wrote:

> On 11/03/2011 08:37 PM, James wrote:
>
>> On Thu, Nov 3, 2011 at 1:52 PM, Alex Samorukov  wrote:
>>
>>> Thank you. I currently got shell, but user-only, what is useless for
>>> me ;-) (All ioctl/cam commands require superuser)
>>>
>>> I asked for the root and now waiting for it. You can also provide
>>> shell so i will have more boxes to test. I am expecting some very
>>> trivial bug caused by some wrong data returned from the driver
>>> without strict check in smartctl.
>>>
>> No problem. Send me your public key privately and I'll set you up.
>>
>>  Could you please try to build latest svn version (see [1]) ? I think i
> fixed this bug.
>
> [1] 
> https://sourceforge.net/apps/**trac/smartmontools/wiki/**Download
>
> __**_
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/**mailman/listinfo/freebsd-**stable
> To unsubscribe, send any mail to 
> "freebsd-stable-unsubscribe@**freebsd.org
> "
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: smartctl / mpt on 9.0-RC1

2011-11-03 Thread Alex Samorukov

On 11/03/2011 08:37 PM, James wrote:

On Thu, Nov 3, 2011 at 1:52 PM, Alex Samorukov  wrote:

Thank you. I currently got shell, but user-only, what is useless for
me ;-) (All ioctl/cam commands require superuser)

I asked for the root and now waiting for it. You can also provide
shell so i will have more boxes to test. I am expecting some very
trivial bug caused by some wrong data returned from the driver
without strict check in smartctl.

 No problem. Send me your public key privately and I'll set you up.

Could you please try to build latest svn version (see [1]) ? I think i 
fixed this bug.


[1] https://sourceforge.net/apps/trac/smartmontools/wiki/Download
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: smartctl / mpt on 9.0-RC1

2011-11-03 Thread Alex Samorukov

Thank you,

it is really caused by MFC r225950 and smartctl way to detect sense 
length.  I decided not to add ifdefs, but change the logic.


I fixed this in SVN [1], patch in the unified diff format could be 
downladed at [2]. Please test this, and if it works fine - i will submit 
PR to the port.


[1] 
https://sourceforge.net/apps/trac/smartmontools/changeset?old_path=%2Ftrunk%2Fsmartmontools%2Fos_freebsd.cpp&old=3468&new_path=%2Ftrunk%2Fsmartmontools%2Fos_freebsd.cpp&new=3467
[2] 
https://sourceforge.net/apps/trac/smartmontools/changeset?format=diff&new=3467&old=3468&new_path=trunk%2Fsmartmontools%2Fos_freebsd.cpp&old_path=trunk%2Fsmartmontools%2Fos_freebsd.cpp




:On 11/03/2011 08:05 PM, Thomas Eberhardt wrote:

Hi. I got the same problem. After some debugging I came up with the
following patch:

--- os_freebsd.cpp.orig 2011-10-06 18:43:44.0 +0200
+++ os_freebsd.cpp  2011-10-23 11:19:31.492599837 +0200
@@ -1044,8 +1044,13 @@
}

if (iop->sensep) {
+#if CAM_VERSION<  0x16
  memcpy(iop->sensep,&(ccb->csio.sense_data),sizeof(struct 
scsi_sense_data));
  iop->resp_sense_len = sizeof(struct scsi_sense_data);
+#else
+memcpy(iop->sensep,&(ccb->csio.sense_data),sizeof(struct 
scsi_sense_data_fixed));
+iop->resp_sense_len = sizeof(struct scsi_sense_data_fixed);
+#endif
}

iop->scsi_status = ccb->csio.scsi_status;



On 03.11.2011, at 19:52, Alex Samorukov wrote:




___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: smartctl / mpt on 9.0-RC1

2011-11-03 Thread James
On Thu, Nov 3, 2011 at 1:52 PM, Alex Samorukov  wrote:
> Thank you. I currently got shell, but user-only, what is useless for
> me ;-) (All ioctl/cam commands require superuser)
>
> I asked for the root and now waiting for it. You can also provide
> shell so i will have more boxes to test. I am expecting some very
> trivial bug caused by some wrong data returned from the driver
> without strict check in smartctl.

No problem. Send me your public key privately and I'll set you up.

-- 
James.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: smartctl / mpt on 9.0-RC1

2011-11-03 Thread Thomas Eberhardt
Hi. I got the same problem. After some debugging I came up with the
following patch:

--- os_freebsd.cpp.orig 2011-10-06 18:43:44.0 +0200
+++ os_freebsd.cpp  2011-10-23 11:19:31.492599837 +0200
@@ -1044,8 +1044,13 @@
   }
 
   if (iop->sensep) {
+#if CAM_VERSION < 0x16
 memcpy(iop->sensep,&(ccb->csio.sense_data),sizeof(struct scsi_sense_data));
 iop->resp_sense_len = sizeof(struct scsi_sense_data);
+#else
+memcpy(iop->sensep,&(ccb->csio.sense_data),sizeof(struct 
scsi_sense_data_fixed));
+iop->resp_sense_len = sizeof(struct scsi_sense_data_fixed);
+#endif
   }
 
   iop->scsi_status = ccb->csio.scsi_status;



On 03.11.2011, at 19:52, Alex Samorukov wrote:

> Thank you. I currently got shell, but user-only, what is useless for me ;-) 
> (All ioctl/cam commands require superuser)
> 
> I asked for the root and now waiting for it. You can also provide shell so i 
> will have more boxes to test. I am expecting some very trivial bug caused by 
> some wrong data returned from the driver without strict check in smartctl.
> 
> On 11/03/2011 07:43 PM, James wrote:
>> On Thu, Nov 3, 2011 at 12:12 PM, Alex Samorukov  wrote:
>>> I am smartmontools developer and FreeBSD port maintainer. If you
>>> could provide shell access to the affected system i can try to debug
>>> issue. I have no access to the mpt devices myself and it is unclear
>>> what going on from provided backtrace.
>> Hi Alex. If you're unable to get shell access from Frank, I'd be
>> glad to help out. I have mps(4) and mpt(4) hardware available and
>> experience the same bug.
>> 
> 
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"



Re: smartctl / mpt on 9.0-RC1

2011-11-03 Thread James
On Thu, Nov 3, 2011 at 12:12 PM, Alex Samorukov  wrote:
> I am smartmontools developer and FreeBSD port maintainer. If you
> could provide shell access to the affected system i can try to debug
> issue. I have no access to the mpt devices myself and it is unclear
> what going on from provided backtrace.

Hi Alex. If you're unable to get shell access from Frank, I'd be
glad to help out. I have mps(4) and mpt(4) hardware available and
experience the same bug.

-- 
James.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: smartctl / mpt on 9.0-RC1

2011-11-03 Thread Alex Samorukov
Thank you. I currently got shell, but user-only, what is useless for me 
;-) (All ioctl/cam commands require superuser)


I asked for the root and now waiting for it. You can also provide shell 
so i will have more boxes to test. I am expecting some very trivial bug 
caused by some wrong data returned from the driver without strict check 
in smartctl.


On 11/03/2011 07:43 PM, James wrote:

On Thu, Nov 3, 2011 at 12:12 PM, Alex Samorukov  wrote:

I am smartmontools developer and FreeBSD port maintainer. If you
could provide shell access to the affected system i can try to debug
issue. I have no access to the mpt devices myself and it is unclear
what going on from provided backtrace.

 Hi Alex. If you're unable to get shell access from Frank, I'd be
 glad to help out. I have mps(4) and mpt(4) hardware available and
 experience the same bug.



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: smartctl / mpt on 9.0-RC1

2011-11-03 Thread Mike Andrews

On 11/3/2011 5:24 AM, Olav Gjerde wrote:

I have the exact same problem with a LSI 3081E-R card and FreeBSD 9-Stable,
compiled yesterday.


I am too, and I'm having trouble getting smartmontools built with 
debugging symbols to get a meaningful coredump.  If I can sort that out 
today, I'll post a backtrace.


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: smartctl / mpt on 9.0-RC1

2011-11-03 Thread Alex Samorukov

Hello,

I am smartmontools developer and FreeBSD port maintainer. If you could 
provide shell access to the affected system i can try to debug issue. I 
have no access to the mpt devices myself and it is unclear what going on 
from provided backtrace.


On 11/03/2011 09:40 AM, Frank Razenberg wrote:



Was this system "upgraded" from RELENG_8 to RELENG_9, or was a fresh
install of 9.x put on it directly?




___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: smartctl / mpt on 9.0-RC1

2011-11-03 Thread Olav Gjerde
I have the exact same problem with a LSI 3081E-R card and FreeBSD 9-Stable,
compiled yesterday.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: smartctl / mpt on 9.0-RC1

2011-11-03 Thread Frank Razenberg



Was this system "upgraded" from RELENG_8 to RELENG_9, or was a fresh
install of 9.x put on it directly?
The system was freshly installed. Prior to my buildworld and 
buildkernel, smartctl didn't work either.

Is there someone else on the list who uses mps(4) on 9.x and has success
using smartmontools?
Actually the mpt driver is used, not the mps driver. Don't know if that 
should make a difference.


It seems my last email did not end up on the list so I'm unsure whether 
it was blocked or what happened.
To summarise: I get a small bit more info at the bottom of the stack 
after building the port with WITH_DEBUG=1.


-Frank

#1086 0x000800fe4338 in std::string::_Rep::_S_empty_rep_storage ()
   from /usr/lib/libstdc++.so.6
#1087 0x in ?? ()
#1088 0x in ?? ()
#1089 0x7fffda00 in ?? ()
#1090 0x in ?? ()
#1091 0x000801ca4b68 in ?? ()
#1092 0x000801ca4b98 in ?? ()
#1093 0x000801ca5578 in ?? ()
---Type  to continue, or q  to quit---
#1094 0x000800fe4338 in std::string::_Rep::_S_empty_rep_storage ()
   from /usr/lib/libstdc++.so.6
#1095 0x000801c831b0 in ?? ()
#1096 0x in ?? ()
#1097 0x0001000101010101 in ?? ()
#1098 0x in ?? ()
#1099 0x7f00 in ?? ()
#1100 0x7fffdb40 in ?? ()
#1101 0x in ?? ()
#1102 0x0008014f7fd2 in __cxa_atexit () from /lib/libc.so.7
#1103 0x0040705c in main (argc=Cannot access memory at address 
0xffd4

) at smartctl.cpp:1129


On 11/3/2011 1:23 AM, Jeremy Chadwick wrote:

On Thu, Nov 03, 2011 at 01:16:17AM +0100, Frank Razenberg wrote:

Sorry, yes, there's actually a lot more, but there's a pattern
repeating over 4 lines.
At #1086 it stops.

Okay.


I also tried with the binary package but it seems to be missing on
the ftp server:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/sysutils/smartmontools-5.42.tbz
gives a 'not found'.
The version from 8-stable can't be used either (Shared object
"libcam.so.5" not found, required by "smartctl").

You won't be able to use a package from RELENG_8 that relies on CAM,
because CAM has been changed significantly between 8 and 9 -- enough
that a library version bump was required.  This is why on your system
"libcam.so.5" can't be found; I'm sure you have libcam.so.6.  Please do
not link the two together either.


The compiler was indeed gcc.

Okay.  As long as you built off of source then the software should
be in sync with underlying library API changes and so on.


.
#36 0x in ?? ()
#37 0x in ?? ()
#38 0x in ?? ()
#39 0x in ?? ()
#40 0x in ?? ()
#41 0x in ?? ()
#42 0x in ?? ()
#43 0x in ?? ()
#44 0x in ?? ()
#45 0x in ?? ()
#46 0x006629d8 in std::string::_Rep::_S_empty_rep_storage ()
#47 0x in ?? ()
#48 0x in ?? ()
#49 0x in ?? ()
#50 0x006629d8 in std::string::_Rep::_S_empty_rep_storage ()
#51 0x in ?? ()
#52 0x in ?? ()
#53 0x in ?? ()
#54 0x006629d8 in std::string::_Rep::_S_empty_rep_storage ()
#55 0x in ?? ()
#56 0x in ?? ()
..
#1062 0x006629d8 in std::string::_Rep::_S_empty_rep_storage ()
#1063 0x in ?? ()
#1064 0x in ?? ()
#1065 0x in ?? ()
#1066 0x006629d8 in std::string::_Rep::_S_empty_rep_storage ()
#1067 0x in ?? ()
#1068 0x in ?? ()
#1069 0x7fffdac0 in ?? ()
#1070 0x7f00 in ?? ()
---Type  to continue, or q  to quit---
#1071 0x000801ca4b68 in ?? ()
#1072 0x000801ca4b98 in ?? ()
#1073 0x000801ca5578 in ?? ()
#1074 0x006629d8 in std::string::_Rep::_S_empty_rep_storage ()
#1075 0x0001000101010101 in ?? ()
#1076 0x in ?? ()
#1077 0x00080100 in ceil () from /lib/libm.so.5
#1078 0x7fffdb00 in ?? ()
#1079 0x0003 in ?? ()
#1080 0x7fffdb00 in ?? ()
#1081 0x7fffdb40 in ?? ()
#1082 0x7fffdb20 in ?? ()
#1083 0x in ?? ()
#1084 0x in ?? ()
#1085 0x00407186 in ?? ()
#1086 0x0040317c in ?? ()
Previous frame inner to this frame (corrupt stack?)
(gdb)

This stack trace is significantly corrupted.  I'm not sure what to say
about this, or how to get a reliable core/crash.

Was this system "upgraded" from RELENG_8 to RELENG_9, or was a fresh
install of 9.x put on it directly?

Is there someone else on the list who uses mps(4) on 9.x and has success
using smartmontools?  What I'm trying to figure out is if this problem
is isolated or not.


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listi

Re: smartctl / mpt on 9.0-RC1

2011-11-02 Thread Xin LI
Hi,

On Wed, Nov 2, 2011 at 4:49 PM, Frank Razenberg  wrote:
>   Loaded symbols for /libexec/ld-elf.so.1
>   #0  0x in ?? ()
>   (gdb) bt
>   #0  0x in ?? ()
>   #1  0x in ?? ()

Your stack is mangled.  Can you recompile and install the port with
'WITH_DEBUG=' and try if you can regenerate the core and gdb to see if
there is any change?

Cheers,
-- 
Xin LI  https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: smartctl / mpt on 9.0-RC1

2011-11-02 Thread Frank Razenberg

A small bit more info appears at the bottom of the stack.
-Frank

#1086 0x000800fe4338 in std::string::_Rep::_S_empty_rep_storage ()
   from /usr/lib/libstdc++.so.6
#1087 0x in ?? ()
#1088 0x in ?? ()
#1089 0x7fffda00 in ?? ()
#1090 0x in ?? ()
#1091 0x000801ca4b68 in ?? ()
#1092 0x000801ca4b98 in ?? ()
#1093 0x000801ca5578 in ?? ()
---Type  to continue, or q  to quit---
#1094 0x000800fe4338 in std::string::_Rep::_S_empty_rep_storage ()
   from /usr/lib/libstdc++.so.6
#1095 0x000801c831b0 in ?? ()
#1096 0x in ?? ()
#1097 0x0001000101010101 in ?? ()
#1098 0x in ?? ()
#1099 0x7f00 in ?? ()
#1100 0x7fffdb40 in ?? ()
#1101 0x in ?? ()
#1102 0x0008014f7fd2 in __cxa_atexit () from /lib/libc.so.7
#1103 0x0040705c in main (argc=Cannot access memory at address 
0xffd4

) at smartctl.cpp:1129


On 11/3/2011 1:23 AM, Xin LI wrote:

Hi,

On Wed, Nov 2, 2011 at 4:49 PM, Frank Razenberg  wrote:

   Loaded symbols for /libexec/ld-elf.so.1
   #0  0x in ?? ()
   (gdb) bt
   #0  0x in ?? ()
   #1  0x in ?? ()

Your stack is mangled.  Can you recompile and install the port with
'WITH_DEBUG=' and try if you can regenerate the core and gdb to see if
there is any change?

Cheers,


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Fwd: Re: smartctl / mpt on 9.0-RC1

2011-11-02 Thread Jeremy Chadwick
Sending original copy to the list.

- Forwarded message from Frank Razenberg  -

> From: Frank Razenberg 
> To: Jeremy Chadwick 
> Date: Thu, 03 Nov 2011 01:16:17 +0100
> Subject: Re: smartctl / mpt on 9.0-RC1
> 
> Sorry, yes, there's actually a lot more, but there's a pattern
> repeating over 4 lines.
> At #1086 it stops.
> 
> I also tried with the binary package but it seems to be missing on
> the ftp server:
> ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/sysutils/smartmontools-5.42.tbz
> gives a 'not found'.
> The version from 8-stable can't be used either (Shared object
> "libcam.so.5" not found, required by "smartctl").
> The compiler was indeed gcc.
> -Frank
> 
> .
> #36 0x in ?? ()
> #37 0x in ?? ()
> #38 0x in ?? ()
> #39 0x in ?? ()
> #40 0x in ?? ()
> #41 0x in ?? ()
> #42 0x in ?? ()
> #43 0x in ?? ()
> #44 0x in ?? ()
> #45 0x in ?? ()
> #46 0x006629d8 in std::string::_Rep::_S_empty_rep_storage ()
> #47 0x in ?? ()
> #48 0x in ?? ()
> #49 0x in ?? ()
> #50 0x006629d8 in std::string::_Rep::_S_empty_rep_storage ()
> #51 0x in ?? ()
> #52 0x in ?? ()
> #53 0x in ?? ()
> #54 0x006629d8 in std::string::_Rep::_S_empty_rep_storage ()
> #55 0x in ?? ()
> #56 0x in ?? ()
> ..
> #1062 0x006629d8 in std::string::_Rep::_S_empty_rep_storage ()
> #1063 0x in ?? ()
> #1064 0x in ?? ()
> #1065 0x in ?? ()
> #1066 0x006629d8 in std::string::_Rep::_S_empty_rep_storage ()
> #1067 0x in ?? ()
> #1068 0x in ?? ()
> #1069 0x7fffdac0 in ?? ()
> #1070 0x7f00 in ?? ()
> ---Type  to continue, or q  to quit---
> #1071 0x000801ca4b68 in ?? ()
> #1072 0x000801ca4b98 in ?? ()
> #1073 0x000801ca5578 in ?? ()
> #1074 0x006629d8 in std::string::_Rep::_S_empty_rep_storage ()
> #1075 0x0001000101010101 in ?? ()
> #1076 0x in ?? ()
> #1077 0x00080100 in ceil () from /lib/libm.so.5
> #1078 0x7fffdb00 in ?? ()
> #1079 0x0003 in ?? ()
> #1080 0x7fffdb00 in ?? ()
> #1081 0x7fffdb40 in ?? ()
> #1082 0x7fffdb20 in ?? ()
> #1083 0x in ?? ()
> #1084 0x in ?? ()
> #1085 0x00407186 in ?? ()
> #1086 0x0040317c in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> (gdb)
> 
> 
> 
> 
> 
> On 11/3/2011 1:01 AM, Jeremy Chadwick wrote:
> >On Thu, Nov 03, 2011 at 12:49:13AM +0100, Frank Razenberg wrote:
> >>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 symbol

Fwd: Re: smartctl / mpt on 9.0-RC1

2011-11-02 Thread Jeremy Chadwick
Forwarding my reply to Frank to the list, because he did not
reply-to-all when sending me the below mail.

-- 
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator   Mountain View, CA, US |
| Making life hard for others since 1977.   PGP 4BD6C0CB |

- Forwarded message from Jeremy Chadwick  -

> From: Jeremy Chadwick 
> To: Frank Razenberg 
> Date: Wed, 2 Nov 2011 17:23:52 -0700
> Subject: Re: smartctl / mpt on 9.0-RC1
> 
> On Thu, Nov 03, 2011 at 01:16:17AM +0100, Frank Razenberg wrote:
> > Sorry, yes, there's actually a lot more, but there's a pattern
> > repeating over 4 lines.
> > At #1086 it stops.
> 
> Okay.
> 
> > I also tried with the binary package but it seems to be missing on
> > the ftp server:
> > ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/sysutils/smartmontools-5.42.tbz
> > gives a 'not found'.
> > The version from 8-stable can't be used either (Shared object
> > "libcam.so.5" not found, required by "smartctl").
> 
> You won't be able to use a package from RELENG_8 that relies on CAM,
> because CAM has been changed significantly between 8 and 9 -- enough
> that a library version bump was required.  This is why on your system
> "libcam.so.5" can't be found; I'm sure you have libcam.so.6.  Please do
> not link the two together either.
> 
> > The compiler was indeed gcc.
> 
> Okay.  As long as you built off of source then the software should
> be in sync with underlying library API changes and so on.
> 
> > .
> > #36 0x in ?? ()
> > #37 0x in ?? ()
> > #38 0x in ?? ()
> > #39 0x in ?? ()
> > #40 0x in ?? ()
> > #41 0x in ?? ()
> > #42 0x in ?? ()
> > #43 0x in ?? ()
> > #44 0x in ?? ()
> > #45 0x in ?? ()
> > #46 0x006629d8 in std::string::_Rep::_S_empty_rep_storage ()
> > #47 0x in ?? ()
> > #48 0x in ?? ()
> > #49 0x in ?? ()
> > #50 0x006629d8 in std::string::_Rep::_S_empty_rep_storage ()
> > #51 0x in ?? ()
> > #52 0x in ?? ()
> > #53 0x in ?? ()
> > #54 0x006629d8 in std::string::_Rep::_S_empty_rep_storage ()
> > #55 0x in ?? ()
> > #56 0x in ?? ()
> > ..
> > #1062 0x006629d8 in std::string::_Rep::_S_empty_rep_storage ()
> > #1063 0x in ?? ()
> > #1064 0x in ?? ()
> > #1065 0x in ?? ()
> > #1066 0x006629d8 in std::string::_Rep::_S_empty_rep_storage ()
> > #1067 0x in ?? ()
> > #1068 0x in ?? ()
> > #1069 0x7fffdac0 in ?? ()
> > #1070 0x7f00 in ?? ()
> > ---Type  to continue, or q  to quit---
> > #1071 0x000801ca4b68 in ?? ()
> > #1072 0x000801ca4b98 in ?? ()
> > #1073 0x000801ca5578 in ?? ()
> > #1074 0x006629d8 in std::string::_Rep::_S_empty_rep_storage ()
> > #1075 0x0001000101010101 in ?? ()
> > #1076 0x in ?? ()
> > #1077 0x00080100 in ceil () from /lib/libm.so.5
> > #1078 0x7fffdb00 in ?? ()
> > #1079 0x0003 in ?? ()
> > #1080 0x7fffdb00 in ?? ()
> > #1081 0x7fffdb40 in ?? ()
> > #1082 0x7fffdb20 in ?? ()
> > #1083 0x in ?? ()
> > #1084 0x in ?? ()
> > #1085 0x00407186 in ?? ()
> > #1086 0x0040317c in ?? ()
> > Previous frame inner to this frame (corrupt stack?)
> > (gdb)
> 
> This stack trace is significantly corrupted.  I'm not sure what to say
> about this, or how to get a reliable core/crash.
> 
> Was this system "upgraded" from RELENG_8 to RELENG_9, or was a fresh
> install of 9.x put on it directly?
> 
> Is there someone else on the list who uses mps(4) on 9.x and has success
> using smartmontools?  What I'm trying to figure out is if this problem
> is isolated or not.
> 
> -- 
> | Jeremy Chadwickjdc at parodius.com |
> | Parodius Networking   http://www.parodius.com/ |
> | UNIX Systems Administrator   Mountain View, CA, US |
> | Making life hard for others since 1977.   PGP 4BD6C0CB |
> 

- End forwarded message -
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: smartctl / mpt on 9.0-RC1

2011-11-02 Thread Jeremy Chadwick
On Thu, Nov 03, 2011 at 12:49:13AM +0100, Frank Razenberg wrote:
> 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  0x in ?? ()
>(gdb) bt
>#0  0x in ?? ()
>#1  0x in ?? ()
>#2  0x in ?? ()
>#3  0x in ?? ()
>#4  0x in ?? ()
>#5  0x in ?? ()
>#6  0x in ?? ()
>#7  0x in ?? ()
>#8  0x in ?? ()
>#9  0x in ?? ()
>#10 0x in ?? ()
>#11 0x in ?? ()
>#12 0x in ?? ()
>#13 0x in ?? ()
>#14 0x in ?? ()
>#15 0x in ?? ()
>#16 0x in ?? ()
>#17 0x in ?? ()
>#18 0x in ?? ()
>#19 0x in ?? ()
>#20 0x in ?? ()
>#21 0x in ?? ()
>#22 0x in ?? ()
>#23 0x in ?? ()
>#24 0x in ?? ()
>#25 0x in ?? ()
>#26 0x in ?? ()
>#27 0x in ?? ()
>#28 0x in ?? ()
>#29 0x in ?? ()
>#30 0x in ?? ()
>#31 0x in ?? ()
>#32 0x in ?? ()
>#33 0x in ?? ()
>#34 0x in ?? ()
>---Type  to continue, or q  to quit---

Is there anything visible further down in the calling frame stack (e.g.
past frame #34)?  Was this built with clang or gcc?  And I assume it was
built from source rather than installed via pkg_add?

-- 
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator   Mountain View, CA, US |
| Making life hard for others since 1977.   PGP 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: smartctl / mpt on 9.0-RC1

2011-11-02 Thread Frank Razenberg
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  0x in ?? ()
   (gdb) bt
   #0  0x in ?? ()
   #1  0x in ?? ()
   #2  0x in ?? ()
   #3  0x in ?? ()
   #4  0x in ?? ()
   #5  0x in ?? ()
   #6  0x in ?? ()
   #7  0x in ?? ()
   #8  0x in ?? ()
   #9  0x in ?? ()
   #10 0x in ?? ()
   #11 0x in ?? ()
   #12 0x in ?? ()
   #13 0x in ?? ()
   #14 0x in ?? ()
   #15 0x in ?? ()
   #16 0x in ?? ()
   #17 0x in ?? ()
   #18 0x in ?? ()
   #19 0x in ?? ()
   #20 0x in ?? ()
   #21 0x in ?? ()
   #22 0x in ?? ()
   #23 0x in ?? ()
   #24 0x in ?? ()
   #25 0x in ?? ()
   #26 0x in ?? ()
   #27 0x in ?? ()
   #28 0x in ?? ()
   #29 0x in ?? ()
   #30 0x in ?? ()
   #31 0x in ?? ()
   #32 0x in ?? ()
   #33 0x in ?? ()
   #34 0x in ?? ()
   ---Type  to continue, or q  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.



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: smartctl / mpt on 9.0-RC1

2011-11-02 Thread Jeremy Chadwick
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.

-- 
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator   Mountain View, CA, US |
| Making life hard for others since 1977.   PGP 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


smartctl / mpt on 9.0-RC1

2011-11-02 Thread Frank Razenberg
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.

Kind regards,
Frank
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"