Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 1 Dec 2013 05:27:02 GMT
From:      Zurvan Akarana <zurvan.akarana@gmail.com>
To:        freebsd-gnats-submit@FreeBSD.org
Subject:   amd64/184405: [regression] [patch] 'mfiutil show drives' from 9.2-REL shows 0.0 size for all drives
Message-ID:  <201312010527.rB15R2No089867@oldred.freebsd.org>
Resent-Message-ID: <201312010530.rB15U0h6007489@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         184405
>Category:       amd64
>Synopsis:       [regression] [patch] 'mfiutil show drives' from 9.2-REL shows 0.0 size for all drives
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-amd64
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Dec 01 05:30:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator:     Zurvan Akarana
>Release:        9.2 RELEASE
>Organization:
N/A
>Environment:
FreeBSD [redacted] 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r255898: Thu Sep 26 22:50:31 UTC 2013     root@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
>Description:
Upgraded to 9.2-RELEASE on Nov. 29, 2013.

Have an LSI-2108-based raid controller supported without issues by mfi(4).

Prior to upgrade 'mfiutil show drives' showed drive sizes correctly.

After upgrade the output became like this

 0 (   0.0) ONLINE <[redacted] serial=[redacted]> SATA E1:S4

I.e., drive size was reported to be 0.0.

All other aspects of mfi(4) that I have tested so far seem to work fine, as they did before.
>How-To-Repeat:
Any run of 'mfiutil show drives' reproduces the problem. I use 3 TB drives connected to the controller but the problem is unaffected by drive size.
>Fix:
Traced the problem to usr.sbin/mfiutil/mfi_show.c file, function print_pd.

It makes a call to humanize_number(3) from libutil and supplies a 256-byte buffer named 'buf' to be filled for this purpose. Then prints it with format string '%6s' which results in this incorrect behavior.

Just using a 6-byte buffer, supplying it to humanize_number(3), and printing it fixes the problem. As seen in the other function print_ld in the same source file.

This bug has been introduced as the larger sized 'buf' was added to source to allow for formatting status messages for foreign configurations present in the array, a new mfiutil functionality.

Patch attached with submission follows:

*** mfi_show.c.orig	2013-12-01 05:21:58.000000000 +0000
--- mfi_show.c	2013-12-01 05:14:48.000000000 +0000
***************
*** 316,330 ****
  
  void
  print_pd(struct mfi_pd_info *info, int state_len)
  {
  	const char *s;
  	char buf[256];
  
! 	humanize_number(buf, sizeof(buf), info->raw_size * 512, "",
  	    HN_AUTOSCALE, HN_B | HN_NOSPACE |HN_DECIMAL);
! 	printf("(%6s) ", buf);
  	if (info->state.ddf.v.pd_type.is_foreign) {
  		sprintf(buf, "%s%s", mfi_pdstate(info->fw_state), foreign_state);
  		s = buf;
  	} else
  		s = mfi_pdstate(info->fw_state);
--- 316,331 ----
  
  void
  print_pd(struct mfi_pd_info *info, int state_len)
  {
  	const char *s;
+ 	char size[6];
  	char buf[256];
  
! 	humanize_number(size, sizeof(size), info->raw_size * 512, "",
  	    HN_AUTOSCALE, HN_B | HN_NOSPACE |HN_DECIMAL);
! 	printf("(%6s) ", size);
  	if (info->state.ddf.v.pd_type.is_foreign) {
  		sprintf(buf, "%s%s", mfi_pdstate(info->fw_state), foreign_state);
  		s = buf;
  	} else
  		s = mfi_pdstate(info->fw_state);


>Release-Note:
>Audit-Trail:
>Unformatted:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201312010527.rB15R2No089867>