Date: Sat, 04 Sep 2004 11:47:21 -0400 From: Eduard Martinescu <martines@rochester.rr.com> To: Don Lewis <dl@catspoiler.org> Cc: scsi@FreeBSD.org Subject: Re: smartmontools on FreeBSD 4.x - compile error + ahc card dump Message-ID: <1094312840.9777.3.camel@sauron.crafts4life.com> In-Reply-To: <200409031840.i83IenAj029786@gw.catspoiler.org> References: <200409031840.i83IenAj029786@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hmm, The compilation problem you mention is fixed in CVS I think...and should be part of the upcoming 5.33 experimental release. Can you try checking out the CVS version of smartmontools to verify? As for the SCSI issues, that is something new. I added the passing in of a time out value because it was causing problems for others without that value...the commands would time out too soon. I myself haven't seen this problem, but then again, I probably don't have the same SCSI controller. Do you see any error output from smartctl? Can you try running with '-r scsiioctl,10' and send me the output? Thanks, Ed On Fri, 2004-09-03 at 14:40, Don Lewis wrote: > The latest version of smartmontools is broken on FreeBSD 4.x (and older > versions of 5.x that don't have the latest version of <inttypes.h>). I > can get the code to compile with the patch below, but then I get runtime > kernel errors. Smartmontools-5.30 seems to work fine on FreeBSD 4.x. > > The only suspicious change that I've seen so far is that > smartmontools-5.32 passes a non-zero timeout to do_scsi_cmnd_io(), which > passes it to cam_fill_csio() and cam_send_ccb(), whereas 5.30 passes > zero in most cases. Suspicion confirmed ... if I force the timeout to > zero in do_scsi_cmnd_io(), smartctl -A works properly. > > > ahc0: Recovery Initiated > >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< > ahc0: Dumping Card State while idle, at SEQADDR 0x8 > Card was paused > ACCUM = 0x4, SINDEX = 0x64, DINDEX = 0x65, ARG_2 = 0x0 > HCNT = 0x0 SCBPTR = 0x19 > SCSIPHASE[0x8]:(MSG_IN_PHASE) SCSISIGI[0xe6]:(REQI|BSYI|MSGI|IOI|CDI) > ERROR[0x0] SCSIBUSL[0x80] LASTPHASE[0x1]:(P_BUSFREE) > SCSISEQ[0x12]:(ENAUTOATNP|ENRSELI) SBLKCTL[0xa]:(SELWIDE|SELBUSB) > SCSIRATE[0x0] SEQCTL[0x10]:(FASTMODE) SEQ_FLAGS[0xc0]:(NO_CDB_SENT|NOT_IDENTIFIED) > SSTAT0[0x20]:(SELDI) SSTAT1[0x19]:(REQINIT|BUSFREE|PHASEMIS) > SSTAT2[0x0] SSTAT3[0x0] SIMODE0[0x8]:(ENSWRAP) SIMODE1[0xac]:(ENSCSIPERR|ENBUSFREE|ENSCSIRST|ENSELTIMO) > SXFRCTL0[0x80]:(DFON) DFCNTRL[0x0] > DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) > STACK: 0x0 0x164 0x179 0x3 > SCB count = 70 > Kernel NEXTQSCB = 25 > Card NEXTQSCB = 25 > QINFIFO entries: > Waiting Queue entries: > Disconnected Queue entries: 25:0 > QOUTFIFO entries: > Sequencer Free SCB List: 18 14 11 7 26 3 13 22 5 8 19 15 6 1 17 28 27 24 30 > 16 10 23 0 4 31 2 9 29 21 20 12 > Sequencer SCB Info: > 0 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] > SCB_LUN[0x0] SCB_TAG[0xff] > 1 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] > SCB_LUN[0x0] SCB_TAG[0xff] > 2 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] > SCB_LUN[0x0] SCB_TAG[0xff] > 3 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] > SCB_LUN[0x0] SCB_TAG[0xff] > 4 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] > SCB_LUN[0x0] SCB_TAG[0xff] > 5 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] > SCB_LUN[0x0] SCB_TAG[0xff] > 6 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] > SCB_LUN[0x0] SCB_TAG[0xff] > 7 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] > SCB_LUN[0x0] SCB_TAG[0xff] > 8 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] > SCB_LUN[0x0] SCB_TAG[0xff] > 9 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] > SCB_LUN[0x0] SCB_TAG[0xff] > 10 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] > SCB_LUN[0x0] SCB_TAG[0xff] > 11 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] > SCB_LUN[0x0] SCB_TAG[0xff] > 12 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x7] > > > > > > ------ Forwarded message ------ > From: Don Lewis <truckman@FreeBSD.org> > Subject: Re: cvs commit: ports/sysutils/smartmontools Makefile > Date: Fri, 3 Sep 2004 10:29:39 -0700 (PDT) > To: stolz@i2.informatik.rwth-aachen.de > > On 3 Sep, Volker Stolz wrote: > > Am 03. Sep 2004 um 11:17 CEST schrieb Don Lewis: > >> On 3 Sep, Volker Stolz wrote: > >> > vs 2004-09-03 08:32:28 UTC > >> > > >> > FreeBSD ports repository > >> > > >> > Modified files: > >> > sysutils/smartmontools Makefile > >> > Log: > >> > Mark as IGNORE for OSVERSION < 501105: Needs ATAng > >> > >> Not quite true. It works fine with SCSI. > > > > But the port doesn't compile. Do you have any patches or could you > > tell me where to start looking? Is there a switch for disabling the > > breaking part of the build?> > > Cheers, > > Volker > > The following patch fixes the compile problem on 4-STABLE. The FreeBSD > version is the closest to when <inttypes.h> was changed to match the > standard. I get a bunch of SCSI errors when I try to run it though. > > --- int64.h.orig Mon Mar 15 11:47:22 2004 > +++ int64.h Fri Sep 3 10:13:56 2004 > @@ -35,6 +35,9 @@ > #ifdef HAVE_STDINT_H > #include <stdint.h> > #else > +#if __FreeBSD_version <= 500042 > +#include <inttypes.h> > +#else > #if defined(_WIN32) && defined(_MSC_VER) > // for MSVC 6.0 > typedef __int64 int64_t; > @@ -44,11 +47,12 @@ > typedef long long int64_t; > typedef unsigned long long uint64_t; > #endif // _WIN32 && _MSC_VER > +#endif // __FreeBSD_version <= 500042 > #endif // HAVE_STDINT_H > #endif // HAVE_SSYS_INT_TYPES_H > // 64 bit integer format strings > > -#ifdef HAVE_INTTYPES_H > +#if defined(HAVE_INTTYPES_H) && __FreeBSD_version > 500042 > #include <inttypes.h> > #else > #if defined(_WIN32) && defined(_MSC_VER) -- Eduard Martinescu <martines@rochester.rr.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1094312840.9777.3.camel>