From owner-freebsd-scsi@FreeBSD.ORG Sun Jan 26 08:52:04 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 593F09D0 for ; Sun, 26 Jan 2014 08:52:04 +0000 (UTC) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 13026158C for ; Sun, 26 Jan 2014 08:52:04 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id cm18so5794138qab.40 for ; Sun, 26 Jan 2014 00:52:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=rci1ag3CZZ83csl977G34pafk0W8zoJoL/i3cVxfjXA=; b=iYcUZmY8Mb3V003ft6LyIcutdTKH0yzeFW/zreWC3CA634VTTqROWRl4TBZs5DDgl2 xijKleTXPckLI8iNcHcmiJlbJhFEY+OGJoWBtwXthIUyWutqWZFLTcrdbI42w5ltGNEr FWzIVxVk1jW81068zo/3UKkkUuo7/C4WstEXjqQ6QXohE00K3NG9VwO3UTX5AyDfbQi1 WL5qS/y3gipiES2m2g+Yqhg9aouLK11BdhJzGeb0MqfRMUTvs+6U0sM4zyln5hMt8OGA W3dwjiNV4YhYEjlOmPf+wXM8DhWiAoZYZJz7HL6z79+4vxwDB7nr4z17tvGKXWJnEwYL 8F/g== MIME-Version: 1.0 X-Received: by 10.229.32.197 with SMTP id e5mr33687324qcd.5.1390726323115; Sun, 26 Jan 2014 00:52:03 -0800 (PST) Sender: benlaurie@gmail.com Received: by 10.96.142.194 with HTTP; Sun, 26 Jan 2014 00:52:03 -0800 (PST) In-Reply-To: <8680A21D-78D7-4B65-A502-17F0C3B70291@scsiguy.com> References: <84D23688-DDC6-421E-9D21-3DA646229038@scsiguy.com> <8680A21D-78D7-4B65-A502-17F0C3B70291@scsiguy.com> Date: Sun, 26 Jan 2014 08:52:03 +0000 X-Google-Sender-Auth: WVQLGPLG8BxPJHJmCOmLRWkckX4 Message-ID: Subject: Re: Dropped interrupts From: Ben Laurie To: "Justin T. Gibbs" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 08:52:04 -0000 On 25 January 2014 17:15, Justin T. Gibbs wrote: > On Jan 24, 2014, at 10:44 PM, Ben Laurie wrote: > >> Aha, finally got the error again=85 > > I don=92t know enough about your backup or Bacula to know if this is amou= nt that should be written, but we attempted a write in variable block mode = of 64512 bytes. I don;t think there's anything wrong with that. Not at the machine right now, but I think that's actually the default max block. No idea why. > The command, data transfer list, and controller state are all consistent= with this. The command was successfully transferred to the tape drive, bu= t it never transitioned to data phase to allow us to begin the data transfe= r. (In parallel SCSI, the target controls all state transitions). > > Since there are no parity errors or other indications of a transport erro= r, my hunch is that this is a tape drive issue. Are you running the latest= available firmware for it? No idea, its a very old LTO-2 drive. I'll see if I can find an update. > How many write cycles do you have on your media? I have seen this error on brand new media. I'd guess the most cycles any tape has had is around 10. > When was the last time you cleaned the drive? LTO drives are self-cleaning. So ... never. > There are still some bugs in the formatting of the diagnostic output for = this driver. I=92ll fix these up and get them into HEAD. > > =97 > Justin From owner-freebsd-scsi@FreeBSD.ORG Sun Jan 26 22:46:15 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A66C85F1 for ; Sun, 26 Jan 2014 22:46:15 +0000 (UTC) Received: from aslan.scsiguy.com (aslan.scsiguy.com [70.89.174.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 53AF41332 for ; Sun, 26 Jan 2014 22:46:14 +0000 (UTC) Received: from [192.168.0.61] (jt-mbp.home.scsiguy.org [192.168.0.61]) (authenticated bits=0) by aslan.scsiguy.com (8.14.7/8.14.7) with ESMTP id s0QMk61D073108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 26 Jan 2014 15:46:08 -0700 (MST) (envelope-from gibbs@scsiguy.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Dropped interrupts From: "Justin T. Gibbs" In-Reply-To: Date: Sun, 26 Jan 2014 15:46:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <888F991A-96C7-48C0-AAC6-0D432BD78A46@scsiguy.com> References: <84D23688-DDC6-421E-9D21-3DA646229038@scsiguy.com> <8680A21D-78D7-4B65-A502-17F0C3B70291@scsiguy.com> To: Ben Laurie X-Mailer: Apple Mail (2.1827) Cc: freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 22:46:15 -0000 On Jan 26, 2014, at 1:52 AM, Ben Laurie wrote: > On 25 January 2014 17:15, Justin T. Gibbs wrote: >> On Jan 24, 2014, at 10:44 PM, Ben Laurie wrote: >>=20 >>> Aha, finally got the error again=85 >>=20 >> I don=92t know enough about your backup or Bacula to know if this is = amount that should be written, but we attempted a write in variable = block mode of 64512 bytes. >=20 > I don;t think there's anything wrong with that. Not at the machine > right now, but I think that's actually the default max block. No idea > why. >=20 >> The command, data transfer list, and controller state are all = consistent with this. The command was successfully transferred to the = tape drive, but it never transitioned to data phase to allow us to begin = the data transfer. (In parallel SCSI, the target controls all state = transitions). >>=20 >> Since there are no parity errors or other indications of a transport = error, my hunch is that this is a tape drive issue. Are you running the = latest available firmware for it? >=20 > No idea, its a very old LTO-2 drive. I'll see if I can find an update. >=20 >> How many write cycles do you have on your media? >=20 > I have seen this error on brand new media. I'd guess the most cycles > any tape has had is around 10. >=20 >> When was the last time you cleaned the drive? >=20 > LTO drives are self-cleaning. So ... never. This is a popular misconception. LTO drives include brushes deployed = during load or unload to remove large particle contamination off the = head. This increases the time interval between traditional cleanings, = but doesn=92t make them unnecessary. Certain LTO drives will tell you = (e.g. light a LED) when they require cleaning, but I don=92t know if = this is one of them. There have also been firmware bugs on some drives = that prevent the cleaning indicator from working as expected. If the drive has over 500 hours on it, I would suggest a cleaning pass. =97 Justin= From owner-freebsd-scsi@FreeBSD.ORG Mon Jan 27 11:06:54 2014 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B313CCD for ; Mon, 27 Jan 2014 11:06:54 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 55F8A1A95 for ; Mon, 27 Jan 2014 11:06:54 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s0RB6s3r013144 for ; Mon, 27 Jan 2014 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0RB6rQi013142 for freebsd-scsi@FreeBSD.org; Mon, 27 Jan 2014 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 27 Jan 2014 11:06:53 GMT Message-Id: <201401271106.s0RB6rQi013142@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-scsi@FreeBSD.org Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 11:06:54 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/184059 scsi [mps] mps SCSI driver causes FreeBSD to hang during bo o kern/179932 scsi [ciss] ciss i/o stall problem with HP Bl Gen8 (and HP o kern/178795 scsi [mps] MSI for mps driver doesn't work under vmware o kern/165982 scsi [mpt] mpt instability, drive resets, and losses on Fre o kern/165740 scsi [cam] SCSI code must drain callbacks before free f kern/162256 scsi [mpt] QUEUE FULL EVENT and 'mpt_cam_event: 0x0' o docs/151336 scsi Missing documentation of scsi_ and ata_ functions in c o kern/148083 scsi [aac] Strange device reporting o kern/144648 scsi [aac] Strange values of speed and bus width in dmesg o kern/142351 scsi [mpt] LSILogic driver performance problems o kern/134488 scsi [mpt] MPT SCSI driver probes max. 8 LUNs per device o kern/130621 scsi [mpt] tranfer rate is inscrutable slow when use lsi213 f kern/129602 scsi [ahd] ahd(4) gets confused and wedges SCSI bus f kern/123674 scsi [ahc] ahc driver dumping o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc 15 problems total. From owner-freebsd-scsi@FreeBSD.ORG Mon Jan 27 06:39:28 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D82C83A; Mon, 27 Jan 2014 06:39:28 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0153.outbound.protection.outlook.com [207.46.163.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8BAB615F3; Mon, 27 Jan 2014 06:39:26 +0000 (UTC) Received: from BN1PR07MB247.namprd07.prod.outlook.com (10.141.64.146) by BN1PR07MB261.namprd07.prod.outlook.com (10.141.64.16) with Microsoft SMTP Server (TLS) id 15.0.859.15; Mon, 27 Jan 2014 06:39:24 +0000 Received: from BN1PR07MB247.namprd07.prod.outlook.com ([169.254.7.198]) by BN1PR07MB247.namprd07.prod.outlook.com ([169.254.7.198]) with mapi id 15.00.0859.020; Mon, 27 Jan 2014 06:39:24 +0000 From: "Desai, Kashyap" To: Doug Ambrisko , Doug Ambrisko Subject: RE: LSI - MR-Fusion controller driver patch and man page Thread-Topic: LSI - MR-Fusion controller driver patch and man page Thread-Index: Ac7ykKZzGPABTpK8R3+D5UAv3TD3WQWOC9SAAHVVybAAG8S5gAAWATMAABupEoADWG5MAAB9D5eA Date: Mon, 27 Jan 2014 06:39:22 +0000 Message-ID: <9751303b9cff49d89dc9dee4d8dda7f1@BN1PR07MB247.namprd07.prod.outlook.com> References: <08ba2a262fba45f687cdd3225f325110@BN1PR07MB247.namprd07.prod.outlook.com> <20140103211449.GA69721@cisco.com> <8c423414ecc2421fbace3eb9f386be91@BN1PR07MB247.namprd07.prod.outlook.com> <20140106182935.GC93278@cisco.com> <20140107181139.GC2080@cisco.com> <20140124185356.GA28724@ambrisko.com> In-Reply-To: <20140124185356.GA28724@ambrisko.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.19.239.250] x-forefront-prvs: 0104247462 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(377454003)(13464003)(51704005)(24454002)(199002)(189002)(164054003)(31966008)(46102001)(51856001)(80976001)(76786001)(74502001)(47446002)(76796001)(83072002)(81816001)(85852003)(54356001)(53806001)(74662001)(74316001)(74366001)(77096001)(76576001)(81686001)(76482001)(56816005)(90146001)(4396001)(19580395003)(33646001)(19580405001)(83322001)(94316002)(74706001)(47976001)(50986001)(87936001)(92566001)(49866001)(47736001)(74876001)(87266001)(80022001)(66066001)(77982001)(85306002)(79102001)(56776001)(59766001)(54316002)(93516002)(86362001)(93136001)(65816001)(69226001)(63696002)(2656002)(81542001)(81342001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR07MB261; H:BN1PR07MB247.namprd07.prod.outlook.com; CLIP:192.19.239.250; FPR:; InfoNoRecordsA:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: lsi.com X-Mailman-Approved-At: Mon, 27 Jan 2014 12:24:38 +0000 Cc: "scottl@netflix.com" , "Radford, Adam" , "Kenneth D. Merry" , "sean_bruno@yahoo.com" , "Mankani, Krishnaraddi" , "dwhite@ixsystems.com" , "Maloy, Joe" , "jpaetzel@freebsd.org" , "freebsd-scsi@freebsd.org" , "McConnell, Stephen" X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 06:39:28 -0000 Doug: This patch looks good and we will work for changes accordingly.=20 We have started checking performance delta between and as sug= gested by you. Till now, we have not seen any issue, if we use Spinning drives. We have se= en issue with SSD, but want to confirm if that is configuration or setup is= sue. Are you seeing issue only if you use SSDs ?? We will contact you to underst= and exact scenario, so that we can root cause from our end. Will spawn new = thread to discuss that. Thanks, ` Kashyap > -----Original Message----- > From: Doug Ambrisko [mailto:ambrisko@ambrisko.com] > Sent: Saturday, January 25, 2014 12:24 AM > To: Doug Ambrisko > Cc: Desai, Kashyap; freebsd-scsi@freebsd.org; scottl@netflix.com; > sean_bruno@yahoo.com; dwhite@ixsystems.com; jpaetzel@freebsd.org; > Maloy, Joe; Mankani, Krishnaraddi; McConnell, Stephen; Saxena, Sumit; > Radford, Adam; Kenneth D. Merry > Subject: Re: LSI - MR-Fusion controller driver patch and man page >=20 > On Tue, Jan 07, 2014 at 10:11:39AM -0800, Doug Ambrisko wrote: > [snip] > | Yes, we can probably make the minimal change to mfi to allow mrsas to > | optionally take over. That can probably be done the quickest. >=20 > Here is the patch I propose to mfi(4) to allow mrsas(4) to optionally tak= e > newer cards. >=20 > Index: mfi_pci.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D > --- mfi_pci.c (revision 260231) > +++ mfi_pci.c (working copy) > @@ -112,6 +112,11 @@ > SYSCTL_INT(_hw_mfi, OID_AUTO, msi, CTLFLAG_RDTUN, &mfi_msi, 0, > "Enable use of MSI interrupts"); >=20 > +static int mfi_mrsas_enable =3D 0; > +TUNABLE_INT("hw.mfi.mrsas_enable", &mfi_msi); SYSCTL_INT(_hw_mfi, > +OID_AUTO, mrsas_enable, CTLFLAG_RDTUN, &mfi_mrsas_enable, > + 0, "Allow mrasas to take newer cards"); > + > struct mfi_ident { > uint16_t vendor; > uint16_t device; > @@ -127,11 +132,11 @@ > {0x1000, 0x005b, 0x1028, 0x1f34, MFI_FLAGS_SKINNY| > MFI_FLAGS_TBOLT, "Dell PERC H710P Mini (monolithics)"}, > {0x1000, 0x005b, 0x1028, 0x1f35, MFI_FLAGS_SKINNY| > MFI_FLAGS_TBOLT, "Dell PERC H710 Adapter"}, > {0x1000, 0x005b, 0x1028, 0x1f37, MFI_FLAGS_SKINNY| > MFI_FLAGS_TBOLT, "Dell PERC H710 Mini (blades)"}, > - {0x1000, 0x005b, 0x1028, 0x1f38, MFI_FLAGS_SKINNY| > MFI_FLAGS_TBOLT, "Dell PERC H710 Mini (monolithics)"}, > - {0x1000, 0x005b, 0x8086, 0x9265, MFI_FLAGS_SKINNY| > MFI_FLAGS_TBOLT, "Intel (R) RAID Controller RS25DB080"}, > - {0x1000, 0x005b, 0x8086, 0x9285, MFI_FLAGS_SKINNY| > MFI_FLAGS_TBOLT, "Intel (R) RAID Controller RS25NB008"}, > - {0x1000, 0x005b, 0xffff, 0xffff, MFI_FLAGS_SKINNY| > MFI_FLAGS_TBOLT, "ThunderBolt"}, > - {0x1000, 0x005d, 0xffff, 0xffff, MFI_FLAGS_SKINNY| > MFI_FLAGS_TBOLT, "Invader"}, > + {0x1000, 0x005b, 0x1028, 0x1f38, MFI_FLAGS_SKINNY| > MFI_FLAGS_TBOLT| MFI_FLAGS_MRSAS, "Dell PERC H710 Mini > (monolithics)"}, > + {0x1000, 0x005b, 0x8086, 0x9265, MFI_FLAGS_SKINNY| > MFI_FLAGS_TBOLT| MFI_FLAGS_MRSAS, "Intel (R) RAID Controller > RS25DB080"}, > + {0x1000, 0x005b, 0x8086, 0x9285, MFI_FLAGS_SKINNY| > MFI_FLAGS_TBOLT| MFI_FLAGS_MRSAS, "Intel (R) RAID Controller > RS25NB008"}, > + {0x1000, 0x005b, 0xffff, 0xffff, MFI_FLAGS_SKINNY| > MFI_FLAGS_TBOLT| MFI_FLAGS_MRSAS, "ThunderBolt"}, > + {0x1000, 0x005d, 0xffff, 0xffff, MFI_FLAGS_SKINNY| > MFI_FLAGS_TBOLT| > +MFI_FLAGS_MRSAS, "Invader"}, > {0x1000, 0x0060, 0x1028, 0xffff, MFI_FLAGS_1078, "Dell PERC 6"}, > {0x1000, 0x0060, 0xffff, 0xffff, MFI_FLAGS_1078, "LSI MegaSAS > 1078"}, > {0x1000, 0x0071, 0xffff, 0xffff, MFI_FLAGS_SKINNY, "Drake Skinny"}, > @@ -178,7 +183,13 @@ >=20 > if ((id =3D mfi_find_ident(dev)) !=3D NULL) { > device_set_desc(dev, id->desc); > - return (BUS_PROBE_DEFAULT); > + > + /* give priority to mrsas if tunable set */ > + TUNABLE_INT_FETCH("hw.mfi.mrsas_enable", > &mfi_mrsas_enable); > + if ((id->flags & MFI_FLAGS_MRSAS) && mfi_mrsas_enable) > + return (BUS_PROBE_LOW_PRIORITY); > + else > + return (BUS_PROBE_DEFAULT); > } > return (ENXIO); > } > Index: mfivar.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D > --- mfivar.h (revision 260231) > +++ mfivar.h (working copy) > @@ -199,6 +199,7 @@ > #define MFI_FLAGS_GEN2 (1<<6) > #define MFI_FLAGS_SKINNY (1<<7) > #define MFI_FLAGS_TBOLT (1<<8) > +#define MFI_FLAGS_MRSAS (1<<9) > // Start: LSIP200113393 > bus_dma_tag_t verbuf_h_dmat; > bus_dmamap_t verbuf_h_dmamap; >=20 > This creates a hw.mfi.mrsas_enable tunable to control it. The method via > hints wasn't the best since for one the unit index was being abused a non= - > unit specfic option. It was also a little strange to have mrsas hint be = in mfi(4). >=20 > Then we need a minor change to mrsas.c >=20 >=20 > --- ../mrsas.orig/mrsas.c 2014-01-03 11:30:28.000000000 -0800 > +++ ./mrsas.c 2014-01-24 10:43:20.000000000 -0800 > @@ -328,25 +328,11 @@ static struct mrsas_ident * mrsas_find_i static in= t > mrsas_probe(device_t dev) { > struct mrsas_ident *id; > - unsigned int force =3D 0, ivar; >=20 > if ((id =3D mrsas_find_ident(dev)) !=3D NULL) { > - if (id->device =3D=3D 0x005b || id->device =3D=3D 0x005d) { > - resource_int_value("mrsas", 0, "fusion_force", &ivar); > - > - if (ivar =3D=3D 0 || ivar =3D=3D 1) > - force =3D ivar; > - > - device_set_desc(dev, id->desc); > - if (force) > - return (BUS_PROBE_DEFAULT); > - //return (BUS_PROBE_SPECIFIC); //give priority to MFI d= river > - else > - return (BUS_PROBE_LOW_PRIORITY); > - } > - else > - device_set_desc(dev, id->desc); > - return (BUS_PROBE_DEFAULT); > + device_set_desc(dev, id->desc); > + /* between BUS_PROBE_DEFAULT and BUS_PROBE_LOW_PRIORITY > */ > + return (-30); > } > return (ENXIO); >=20 > So that its probe part way between mfi(4) results and then it doesn't hav= e to > change. >=20 > If no one has concerns then I'll check in the mfi(4) change. >=20 > Thanks, >=20 > Doug A. From owner-freebsd-scsi@FreeBSD.ORG Tue Jan 28 17:35:32 2014 Return-Path: Delivered-To: scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF5FCB0C; Tue, 28 Jan 2014 17:35:32 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 951121506; Tue, 28 Jan 2014 17:35:32 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7DC71B9DB; Tue, 28 Jan 2014 12:35:31 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: Instant panic CAM or USB subsystem Date: Tue, 28 Jan 2014 12:32:21 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <20140125172106.GA67590@troutmask.apl.washington.edu> In-Reply-To: <20140125172106.GA67590@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201401281232.21958.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 28 Jan 2014 12:35:31 -0500 (EST) Cc: Alexander Motin , Steve Kargl , scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 17:35:32 -0000 On Saturday, January 25, 2014 12:21:06 pm Steve Kargl wrote: > If I plug my Samsung Intensity II cellphone into a usb port, > I get an instant panic. This is 100% reproducible. I have > the core and kernel for further debugging. Dmesg.boot follows > my sig. > > % kgdb /boot/kernel/kernel /vmcore.0 > > Unread portion of the kernel message buffer: > cd1 at umass-sim1 bus 1 scbus4 target 0 lun 0 > cd1: Removable CD-ROM SCSI-2 device > cd1: Serial Number 000000000002 > cd1: 1.000MB/s transfers > cd1: cd present [3840000 x 512 byte records] > cd1: quirks=0x10<10_BYTE_ONLY> > panic: mutex CAM device lock not owned at /usr/src/sys/cam/cam_periph.c:301 > cpuid = 0 > KDB: enter: panic scsi@ might work better for this. It looks like when cdasync() calls cam_periph_alloc() it doesn't have its associated xpt_path locked. All the other async xpt callbacks I looked at don't lock the xpt path either. It seems they expect it to be locked by the caller when they are invoked. It seems xpt_async_process_dev() doesn't always lock xpt_lock, but sometimes locks the device instead: /* * If async for specific device is to be delivered to * the wildcard client, take the specific device lock. * XXX: We may need a way for client to specify it. */ if ((device->lun_id == CAM_LUN_WILDCARD && path->device->lun_id != CAM_LUN_WILDCARD) || (device->target->target_id == CAM_TARGET_WILDCARD && path->target->target_id != CAM_TARGET_WILDCARD) || (device->target->bus->path_id == CAM_BUS_WILDCARD && path->target->bus->path_id != CAM_BUS_WILDCARD)) { mtx_unlock(&device->device_mtx); xpt_path_lock(path); relock = 1; } else relock = 0; (*(device->target->bus->xport->async))(async_code, device->target->bus, device->target, device, async_arg); xpt_async_bcast(&device->asyncs, async_code, path, async_arg); if (relock) { xpt_path_unlock(path); mtx_lock(&device->device_mtx); } Maybe try going up to this frame (16) in your dump and do 'p *device->target'? However, someone with more CAM knowledge needs to look at this to see what is actually broken. It seems a bit odd that it thinks your phone is a CD player. -- John Baldwin From owner-freebsd-scsi@FreeBSD.ORG Tue Jan 28 17:53:53 2014 Return-Path: Delivered-To: scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80B093E3; Tue, 28 Jan 2014 17:53:53 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 592AC16F7; Tue, 28 Jan 2014 17:53:52 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s0SHrqRM077749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jan 2014 09:53:52 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s0SHrqHX077748; Tue, 28 Jan 2014 09:53:52 -0800 (PST) (envelope-from jmg) Date: Tue, 28 Jan 2014 09:53:52 -0800 From: John-Mark Gurney To: John Baldwin Subject: Re: Instant panic CAM or USB subsystem Message-ID: <20140128175352.GB13704@funkthat.com> Mail-Followup-To: John Baldwin , freebsd-current@freebsd.org, Alexander Motin , Steve Kargl , scsi@freebsd.org References: <20140125172106.GA67590@troutmask.apl.washington.edu> <201401281232.21958.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201401281232.21958.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 28 Jan 2014 09:53:52 -0800 (PST) Cc: Alexander Motin , freebsd-current@freebsd.org, Steve Kargl , scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 17:53:53 -0000 John Baldwin wrote this message on Tue, Jan 28, 2014 at 12:32 -0500: > It seems a bit odd that it thinks your phone is a CD player. I've seen a phone that acts like that, they use it to present software (like sync) for install on the desktop... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-scsi@FreeBSD.ORG Tue Jan 28 19:58:48 2014 Return-Path: Delivered-To: scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C3F6D54; Tue, 28 Jan 2014 19:58:48 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6D1DF1365; Tue, 28 Jan 2014 19:58:48 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id s0SJwgCQ083208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Jan 2014 11:58:42 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id s0SJwgE5083207; Tue, 28 Jan 2014 11:58:42 -0800 (PST) (envelope-from sgk) Date: Tue, 28 Jan 2014 11:58:42 -0800 From: Steve Kargl To: John Baldwin Subject: Re: Instant panic CAM or USB subsystem Message-ID: <20140128195842.GA83173@troutmask.apl.washington.edu> References: <20140125172106.GA67590@troutmask.apl.washington.edu> <201401281232.21958.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201401281232.21958.jhb@freebsd.org> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: Alexander Motin , freebsd-current@freebsd.org, scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 19:58:48 -0000 On Tue, Jan 28, 2014 at 12:32:21PM -0500, John Baldwin wrote: > On Saturday, January 25, 2014 12:21:06 pm Steve Kargl wrote: > > If I plug my Samsung Intensity II cellphone into a usb port, > > I get an instant panic. This is 100% reproducible. I have > > the core and kernel for further debugging. Dmesg.boot follows > > my sig. > > > > % kgdb /boot/kernel/kernel /vmcore.0 > > > > Unread portion of the kernel message buffer: > > cd1 at umass-sim1 bus 1 scbus4 target 0 lun 0 > > cd1: Removable CD-ROM SCSI-2 device > > cd1: Serial Number 000000000002 > > cd1: 1.000MB/s transfers > > cd1: cd present [3840000 x 512 byte records] > > cd1: quirks=0x10<10_BYTE_ONLY> > > panic: mutex CAM device lock not owned at /usr/src/sys/cam/cam_periph.c:301 > > cpuid = 0 > > KDB: enter: panic > > scsi@ might work better for this. It looks like when cdasync() calls > cam_periph_alloc() it doesn't have its associated xpt_path locked. All the > other async xpt callbacks I looked at don't lock the xpt path either. It > seems they expect it to be locked by the caller when they are invoked. It > seems xpt_async_process_dev() doesn't always lock xpt_lock, but sometimes > locks the device instead: > > /* > * If async for specific device is to be delivered to > * the wildcard client, take the specific device lock. > * XXX: We may need a way for client to specify it. > */ > if ((device->lun_id == CAM_LUN_WILDCARD && > path->device->lun_id != CAM_LUN_WILDCARD) || > (device->target->target_id == CAM_TARGET_WILDCARD && > path->target->target_id != CAM_TARGET_WILDCARD) || > (device->target->bus->path_id == CAM_BUS_WILDCARD && > path->target->bus->path_id != CAM_BUS_WILDCARD)) { > mtx_unlock(&device->device_mtx); > xpt_path_lock(path); > relock = 1; > } else > relock = 0; > > (*(device->target->bus->xport->async))(async_code, > device->target->bus, device->target, device, async_arg); > xpt_async_bcast(&device->asyncs, async_code, path, async_arg); > > if (relock) { > xpt_path_unlock(path); > mtx_lock(&device->device_mtx); > } > > Maybe try going up to this frame (16) in your dump and do > 'p *device->target'? However, someone with more CAM knowledge needs to look > at this to see what is actually broken. > > It seems a bit odd that it thinks your phone is a CD player. Thanks for the follow-up. I poked around a bit, but don't recall looking at *device->target. Under Windows, 3 filesystems show up, and the one causing problems is listed as CDFS. I'm travaling this week for owrk, so may not be able to follow-up with more info until Sunday. -- Steve From owner-freebsd-scsi@FreeBSD.ORG Tue Jan 28 20:07:22 2014 Return-Path: Delivered-To: scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C5BC13B; Tue, 28 Jan 2014 20:07:22 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D1CBE146B; Tue, 28 Jan 2014 20:07:21 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id s0SK7LL8083250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Jan 2014 12:07:21 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id s0SK7LZX083249; Tue, 28 Jan 2014 12:07:21 -0800 (PST) (envelope-from sgk) Date: Tue, 28 Jan 2014 12:07:21 -0800 From: Steve Kargl To: John Baldwin , freebsd-current@freebsd.org, Alexander Motin , scsi@freebsd.org Subject: Re: Instant panic CAM or USB subsystem Message-ID: <20140128200721.GB83173@troutmask.apl.washington.edu> References: <20140125172106.GA67590@troutmask.apl.washington.edu> <201401281232.21958.jhb@freebsd.org> <20140128175352.GB13704@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140128175352.GB13704@funkthat.com> User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 20:07:22 -0000 On Tue, Jan 28, 2014 at 09:53:52AM -0800, John-Mark Gurney wrote: > John Baldwin wrote this message on Tue, Jan 28, 2014 at 12:32 -0500: > > It seems a bit odd that it thinks your phone is a CD player. > > I've seen a phone that acts like that, they use it to present software > (like sync) for install on the desktop... > Yes, that appears to be the problem. Under Windows, the phone shows 3 filesystems and the problematic one reports CDFS. I should note that I've plugged this phone into this laptop for a few years without any issues. I unfortunately updated a circa Aug 2013 freebsd-current to a week old -current. It has not been a pleasant experience. Unzipping or untarring a large compressed archive onto a USB mounted hard drive renders the system unusable for minutes at a time. unzip and bsdtar are stuck in getblk or wdrain for 30 to 60 seconds. System recovers for a few seconds then get stuck again. Rinse and repeat. I'm not sure if it is a UFS2 or USB or some other change. -- Steve From owner-freebsd-scsi@FreeBSD.ORG Wed Jan 29 18:45:12 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04F6A7E; Wed, 29 Jan 2014 18:45:12 +0000 (UTC) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [IPv6:2001:470:8b2d:1e1c:21b:21ff:feb8:d7b0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 960A218E7; Wed, 29 Jan 2014 18:45:10 +0000 (UTC) Received: from khavrinen.csail.mit.edu (localhost [127.0.0.1]) by khavrinen.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s0TIj8Be046913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL CN=khavrinen.csail.mit.edu issuer=Client+20CA); Wed, 29 Jan 2014 13:45:09 -0500 (EST) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.14.7/8.14.7/Submit) id s0TIj8Xk046910; Wed, 29 Jan 2014 13:45:08 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21225.19508.683025.581620@khavrinen.csail.mit.edu> Date: Wed, 29 Jan 2014 13:45:08 -0500 From: Garrett Wollman To: freebsd-stable@freebsd.org, freebsd-scsi@freebsd.org Subject: stable/9 mps(4) rev 254938 == BOOM! X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (khavrinen.csail.mit.edu [127.0.0.1]); Wed, 29 Jan 2014 13:45:09 -0500 (EST) Cc: scottl@freebsd.org, ken@freebsd.org, hselasky@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 18:45:12 -0000 I've been trying to puzzle out why the USB stack hits a GPF during boot on 9-stable on one of my machines (which runs 9.2 just fine), and by trial and error I've found that it is actually caused by r254938, which is a mega-MFC of mps(4) driver changes, even though the fault always occurs at the same place in a harmless USB subroutine. Details below; config available on request. -GAWollman Here is a verbose boot from r254938, with the crash: OK set debug.debugger_on_panic=1 OK boot -v Booting... KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=000000000009c800 SMAP type=02 base=000000000009c800 len=0000000000003800 SMAP type=02 base=00000000000e0000 len=0000000000020000 SMAP type=01 base=0000000000100000 len=00000000bf660000 SMAP type=01 base=00000000bf76e000 len=0000000000002000 SMAP type=03 base=00000000bf770000 len=000000000000e000 SMAP type=04 base=00000000bf77e000 len=0000000000052000 SMAP type=02 base=00000000bf7d0000 len=0000000000010000 SMAP type=02 base=00000000bf7ec000 len=0000000000014000 SMAP type=02 base=00000000bf800000 len=0000000000800000 SMAP type=02 base=00000000e0000000 len=0000000010000000 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=02 base=00000000ffc00000 len=0000000000400000 SMAP type=01 base=0000000100000000 len=0000001340000000 Table 'FACP' at 0xbf770290 Table 'APIC' at 0xbf770390 APIC: Found table at 0xbf770390 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 2 ACPI ID 2: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 4 ACPI ID 3: enabled SMP: Added CPU 4 (AP) MADT: Found CPU APIC ID 16 ACPI ID 4: enabled SMP: Added CPU 16 (AP) MADT: Found CPU APIC ID 18 ACPI ID 5: enabled SMP: Added CPU 18 (AP) MADT: Found CPU APIC ID 20 ACPI ID 6: enabled SMP: Added CPU 20 (AP) MADT: Found CPU APIC ID 32 ACPI ID 7: enabled SMP: Added CPU 32 (AP) MADT: Found CPU APIC ID 34 ACPI ID 8: enabled SMP: Added CPU 34 (AP) MADT: Found CPU APIC ID 36 ACPI ID 9: enabled SMP: Added CPU 36 (AP) MADT: Found CPU APIC ID 48 ACPI ID 10: enabled SMP: Added CPU 48 (AP) MADT: Found CPU APIC ID 50 ACPI ID 11: enabled SMP: Added CPU 50 (AP) MADT: Found CPU APIC ID 52 ACPI ID 12: enabled SMP: Added CPU 52 (AP) MADT: Found CPU APIC ID 1 ACPI ID 13: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 3 ACPI ID 14: enabled SMP: Added CPU 3 (AP) MADT: Found CPU APIC ID 5 ACPI ID 15: enabled SMP: Added CPU 5 (AP) MADT: Found CPU APIC ID 17 ACPI ID 16: enabled SMP: Added CPU 17 (AP) MADT: Found CPU APIC ID 19 ACPI ID 17: enabled SMP: Added CPU 19 (AP) MADT: Found CPU APIC ID 21 ACPI ID 18: enabled SMP: Added CPU 21 (AP) MADT: Found CPU APIC ID 33 ACPI ID 19: enabled SMP: Added CPU 33 (AP) MADT: Found CPU APIC ID 35 ACPI ID 20: enabled SMP: Added CPU 35 (AP) MADT: Found CPU APIC ID 37 ACPI ID 21: enabled SMP: Added CPU 37 (AP) MADT: Found CPU APIC ID 49 ACPI ID 22: enabled SMP: Added CPU 49 (AP) MADT: Found CPU APIC ID 51 ACPI ID 23: enabled SMP: Added CPU 51 (AP) MADT: Found CPU APIC ID 53 ACPI ID 24: enabled SMP: Added CPU 53 (AP) Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.2-PRERELEASE #14 r254938M: Wed Jan 29 12:29:49 EST 2014 wollman@xyz.csail.mit.edu:/usr/obj/usr/src-9-stable/sys/CSAIL amd64 gcc version 4.2.1 20070831 patched [FreeBSD] Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff81480000. Preloaded elf obj module "/boot/kernel/zfs.ko" at 0xffffffff81480270. Preloaded elf obj module "/boot/kernel/opensolaris.ko" at 0xffffffff81480958. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff81480fc8. Calibrating TSC clock ... TSC clock: 2933495320 Hz CPU: Intel(R) Xeon(R) CPU X5670 @ 2.93GHz (2933.50-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x206c2 Family = 0x6 Model = 0x2c Stepping = 2 Features=0xbfebfbff Features2=0x29ee3ff AMD Features=0x2c100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 85899345920 (81920 MB) Physical memory chunk(s): 0x0000000000010000 - 0x0000000000098fff, 561152 bytes (137 pages) 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) 0x00000000014ac000 - 0x00000000bf75ffff, 3190505472 bytes (778932 pages) 0x00000000bf76e000 - 0x00000000bf76ffff, 8192 bytes (2 pages) 0x0000000100000000 - 0x00000013a7c71fff, 80124256256 bytes (19561586 pages) avail memory = 83076120576 (79227 MB) INTR: Adding local APIC 0 as a target Event timer "LAPIC" quality 600 ACPI APIC Table: <081711 APIC1011> INTR: Adding local APIC 0 as a target INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 5 as a target INTR: Adding local APIC 16 as a target INTR: Adding local APIC 17 as a target INTR: Adding local APIC 18 as a target INTR: Adding local APIC 19 as a target INTR: Adding local APIC 20 as a target INTR: Adding local APIC 21 as a target INTR: Adding local APIC 32 as a target INTR: Adding local APIC 33 as a target INTR: Adding local APIC 34 as a target INTR: Adding local APIC 35 as a target INTR: Adding local APIC 36 as a target INTR: Adding local APIC 37 as a target INTR: Adding local APIC 48 as a target INTR: Adding local APIC 49 as a target INTR: Adding local APIC 50 as a target INTR: Adding local APIC 51 as a target INTR: Adding local APIC 52 as a target INTR: Adding local APIC 53 as a target FreeBSD/SMP: Multiprocessor System Detected: 24 CPUs FreeBSD/SMP: 2 package(s) x 6 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 16 cpu7 (AP): APIC ID: 17 cpu8 (AP): APIC ID: 18 cpu9 (AP): APIC ID: 19 cpu10 (AP): APIC ID: 20 cpu11 (AP): APIC ID: 21 cpu12 (AP): APIC ID: 32 cpu13 (AP): APIC ID: 33 cpu14 (AP): APIC ID: 34 cpu15 (AP): APIC ID: 35 cpu16 (AP): APIC ID: 36 cpu17 (AP): APIC ID: 37 cpu18 (AP): APIC ID: 48 cpu19 (AP): APIC ID: 49 cpu20 (AP): APIC ID: 50 cpu21 (AP): APIC ID: 51 cpu22 (AP): APIC ID: 52 cpu23 (AP): APIC ID: 53 x86bios: IVT 0x000000-0x0004ff at 0xfffffe0000000000 x86bios: SSEG 0x098000-0x098fff at 0xffffff80003ad000 x86bios: EBDA 0x09c000-0x09ffff at 0xfffffe000009c000 x86bios: ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 lapic0: CMCI unmasked APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 13 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 14 APIC: CPU 4 has ACPI ID 3 APIC: CPU 5 has ACPI ID 15 APIC: CPU 6 has ACPI ID 4 APIC: CPU 7 has ACPI ID 16 APIC: CPU 8 has ACPI ID 5 APIC: CPU 9 has ACPI ID 17 APIC: CPU 10 has ACPI ID 6 APIC: CPU 11 has ACPI ID 18 APIC: CPU 12 has ACPI ID 7 APIC: CPU 13 has ACPI ID 19 APIC: CPU 14 has ACPI ID 8 APIC: CPU 15 has ACPI ID 20 APIC: CPU 16 has ACPI ID 9 APIC: CPU 17 has ACPI ID 21 APIC: CPU 18 has ACPI ID 10 APIC: CPU 19 has ACPI ID 22 APIC: CPU 20 has ACPI ID 11 APIC: CPU 21 has ACPI ID 23 APIC: CPU 22 has ACPI ID 12 APIC: CPU 23 has ACPI ID 24 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ULE: setup cpu 4 ULE: setup cpu 5 ULE: setup cpu 6 ULE: setup cpu 7 ULE: setup cpu 8 ULE: setup cpu 9 ULE: setup cpu 10 ULE: setup cpu 11 ULE: setup cpu 12 ULE: setup cpu 13 ULE: setup cpu 14 ULE: setup cpu 15 ULE: setup cpu 16 ULE: setup cpu 17 ULE: setup cpu 18 ULE: setup cpu 19 ULE: setup cpu 20 ULE: setup cpu 21 ULE: setup cpu 22 ULE: setup cpu 23 ACPI: RSDP 0xfadb0 00024 (v02 ACPIAM) ACPI: XSDT 0xbf770100 0008C (v01 081711 XSDT1011 20110817 MSFT 00000097) ACPI: FACP 0xbf770290 000F4 (v03 081711 FACP1011 20110817 MSFT 00000097) ACPI: DSDT 0xbf7705d0 05DDD (v01 Z99Q3 Z99Q3A03 00000A03 INTL 20051117) ACPI: FACS 0xbf77e000 00040 ACPI: APIC 0xbf770390 001AE (v01 081711 APIC1011 20110817 MSFT 00000097) ACPI: SPCR 0xbf770540 00050 (v01 081711 SPCR1011 20110817 MSFT 00000097) ACPI: MCFG 0xbf770590 0003C (v01 081711 OEMMCFG 20110817 MSFT 00000097) ACPI: SSDT 0xbf77a5d0 0002A (v01 OEM_ID OEMTBLID 00000001 INTL 20051117) ACPI: OEMB 0xbf77e040 00083 (v01 081711 OEMB1011 20110817 MSFT 00000097) ACPI: SRAT 0xbf77a600 00250 (v01 081711 OEMSRAT 00000001 INTL 00000001) ACPI: HPET 0xbf77a850 00038 (v01 081711 OEMHPET 20110817 MSFT 00000097) ACPI: SSDT 0xbf7857b0 00363 (v01 DpgPmm CpuPm 00000012 INTL 20051117) ACPI: EINJ 0xbf77a890 00130 (v01 AMIER AMI_EINJ 20110817 MSFT 00000097) ACPI: BERT 0xbf77aa20 00030 (v01 AMIER AMI_BERT 20110817 MSFT 00000097) ACPI: ERST 0xbf77aa50 001B0 (v01 AMIER AMI_ERST 20110817 MSFT 00000097) ACPI: HEST 0xbf77ac00 000A8 (v01 AMIER ABC_HEST 20110817 MSFT 00000097) MADT: Found IO APIC ID 6, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Found IO APIC ID 7, Interrupt 24 at 0xfec8a000 ioapic1: Changing APIC ID to 7 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic2: Routing NMI -> LINT1 lapic2: LINT1 trigger: edge lapic2: LINT1 polarity: high lapic4: Routing NMI -> LINT1 lapic4: LINT1 trigger: edge lapic4: LINT1 polarity: high lapic16: Routing NMI -> LINT1 lapic16: LINT1 trigger: edge lapic16: LINT1 polarity: high lapic18: Routing NMI -> LINT1 lapic18: LINT1 trigger: edge lapic18: LINT1 polarity: high lapic20: Routing NMI -> LINT1 lapic20: LINT1 trigger: edge lapic20: LINT1 polarity: high lapic32: Routing NMI -> LINT1 lapic32: LINT1 trigger: edge lapic32: LINT1 polarity: high lapic34: Routing NMI -> LINT1 lapic34: LINT1 trigger: edge lapic34: LINT1 polarity: high lapic36: Routing NMI -> LINT1 lapic36: LINT1 trigger: edge lapic36: LINT1 polarity: high lapic48: Routing NMI -> LINT1 lapic48: LINT1 trigger: edge lapic48: LINT1 polarity: high lapic50: Routing NMI -> LINT1 lapic50: LINT1 trigger: edge lapic50: LINT1 polarity: high lapic52: Routing NMI -> LINT1 lapic52: LINT1 trigger: edge lapic52: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high lapic3: Routing NMI -> LINT1 lapic3: LINT1 trigger: edge lapic3: LINT1 polarity: high lapic5: Routing NMI -> LINT1 lapic5: LINT1 trigger: edge lapic5: LINT1 polarity: high lapic17: Routing NMI -> LINT1 lapic17: LINT1 trigger: edge lapic17: LINT1 polarity: high lapic19: Routing NMI -> LINT1 lapic19: LINT1 trigger: edge lapic19: LINT1 polarity: high lapic21: Routing NMI -> LINT1 lapic21: LINT1 trigger: edge lapic21: LINT1 polarity: high lapic33: Routing NMI -> LINT1 lapic33: LINT1 trigger: edge lapic33: LINT1 polarity: high lapic35: Routing NMI -> LINT1 lapic35: LINT1 trigger: edge lapic35: LINT1 polarity: high lapic37: Routing NMI -> LINT1 lapic37: LINT1 trigger: edge lapic37: LINT1 polarity: high lapic49: Routing NMI -> LINT1 lapic49: LINT1 trigger: edge lapic49: LINT1 polarity: high lapic51: Routing NMI -> LINT1 lapic51: LINT1 trigger: edge lapic51: LINT1 polarity: high lapic53: Routing NMI -> LINT1 lapic53: LINT1 trigger: edge lapic53: LINT1 polarity: high MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic: Routing NMI -> LINT1 lapic: LINT1 trigger: edge lapic: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 firmware: 't4fw_cfg' version 0: 2917 bytes loaded at 0xffffffff80d4bf64 firmware: 't4fw_cfg_uwire' version 0: 20576 bytes loaded at 0xffffffff80d4cac9 firmware: 't4fw' version 0: 478208 bytes loaded at 0xffffffff80d51b29 firmware: 't5fw_cfg' version 0: 3111 bytes loaded at 0xffffffff80dc6804 firmware: 't5fw' version 0: 460800 bytes loaded at 0xffffffff80dc742b firmware: 'isp_1040' version 1: 22944 bytes loaded at 0xffffffff80934c00 ispfw: registered firmware firmware: 'isp_1040_it' version 1: 32942 bytes loaded at 0xffffffff8093a5a0 ispfw: registered firmware firmware: 'isp_1080' version 1: 31350 bytes loaded at 0xffffffff80942660 ispfw: registered firmware firmware: 'isp_1080_it' version 1: 40644 bytes loaded at 0xffffffff8094a0e0 ispfw: registered firmware firmware: 'isp_12160' version 1: 28050 bytes loaded at 0xffffffff80953fc0 ispfw: registered firmware firmware: 'isp_12160_it' version 1: 40604 bytes loaded at 0xffffffff8095ad60 ispfw: registered firmware firmware: 'isp_2100' version 1: 76770 bytes loaded at 0xffffffff80964c00 ispfw: registered firmware firmware: 'isp_2200' version 1: 77214 bytes loaded at 0xffffffff80977800 ispfw: registered firmware firmware: 'isp_2300' version 1: 113630 bytes loaded at 0xffffffff8098a5a0 ispfw: registered firmware firmware: 'isp_2322' version 1: 120466 bytes loaded at 0xffffffff809a6180 ispfw: registered firmware firmware: 'isp_2400' version 1: 178924 bytes loaded at 0xffffffff809c7380 ispfw: registered firmware firmware: 'isp_2400_multi' version 1: 195276 bytes loaded at 0xffffffff809ffde0 ispfw: registered firmware firmware: 'isp_2500' version 1: 141884 bytes loaded at 0xffffffff80a3d2e0 ispfw: registered firmware firmware: 'isp_2500_multi' version 1: 166508 bytes loaded at 0xffffffff80a6ee40 ispfw: registered firmware cpuctl: access to MSR registers/cpuid info. io: nfslock: pseudo-device crypto: null: random: kbd: new array size 4 kbd1 at kbdmux0 mem: smbios0: at iomem 0xfbe70-0xfbe8e on motherboard smbios0: Version: 2.5 cryptosoft0: on motherboard crypto: assign cryptosoft0 driver id 0, flags 100663296 crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 22 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 aesni0: on motherboard crypto: assign aesni0 driver id 1, flags 16777216 crypto: aesni0 registers alg 11 flags 0 maxoplen 0 crypto: aesni0 registers alg 22 flags 0 maxoplen 0 acpi0: <081711 XSDT1011> on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 ACPI: Executed 1 blocks of module-level executable AML code acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of e0000, 20000 (3) failed acpi0: reservation of 100000, bff00000 (3) failed cpu0: Processor \_PR_.P001 (ACPI ID 1) -> APIC ID 0 cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - 0x35, should be 0x32 (20110527/tbutils-282) ACPI: SSDT 0xbf77e0d0 0603C (v01 DpgPmm P001Ist 00000011 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 0603C (v01 DpgPmm P001Ist 00000011 INTL 20051117) ACPI: SSDT 0xbf784110 00C88 (v01 PmRef P001Cst 00003001 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00C88 (v01 PmRef P001Cst 00003001 INTL 20051117) ACPI: SSDT 0xbf784da0 00A0A (v01 PmRef Cpu0Tst 00003000 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00A0A (v01 PmRef Cpu0Tst 00003000 INTL 20051117) cpu1: Processor \_PR_.P002 (ACPI ID 2) -> APIC ID 2 cpu1: on acpi0 cpu2: Processor \_PR_.P003 (ACPI ID 3) -> APIC ID 4 cpu2: on acpi0 cpu3: Processor \_PR_.P004 (ACPI ID 4) -> APIC ID 6 cpu3: on acpi0 cpu4: Processor \_PR_.P005 (ACPI ID 5) -> APIC ID 8 cpu4: on acpi0 cpu5: Processor \_PR_.P006 (ACPI ID 6) -> APIC ID 10 cpu5: on acpi0 cpu6: Processor \_PR_.P007 (ACPI ID 7) -> APIC ID 12 cpu6: on acpi0 cpu7: Processor \_PR_.P008 (ACPI ID 8) -> APIC ID 14 cpu7: on acpi0 cpu8: Processor \_PR_.P009 (ACPI ID 9) -> APIC ID 16 cpu8: on acpi0 cpu9: Processor \_PR_.P010 (ACPI ID 10) -> APIC ID 18 cpu9: on acpi0 cpu10: Processor \_PR_.P011 (ACPI ID 11) -> APIC ID 20 cpu10: on acpi0 cpu11: Processor \_PR_.P012 (ACPI ID 12) -> APIC ID 22 cpu11: on acpi0 cpu12: Processor \_PR_.P013 (ACPI ID 13) -> APIC ID 1 cpu12: on acpi0 cpu13: Processor \_PR_.P014 (ACPI ID 14) -> APIC ID 3 cpu13: on acpi0 cpu14: Processor \_PR_.P015 (ACPI ID 15) -> APIC ID 5 cpu14: on acpi0 cpu15: Processor \_PR_.P016 (ACPI ID 16) -> APIC ID 7 cpu15: on acpi0 cpu16: Processor \_PR_.P017 (ACPI ID 17) -> APIC ID 9 cpu16: on acpi0 cpu17: Processor \_PR_.P018 (ACPI ID 18) -> APIC ID 11 cpu17: on acpi0 cpu18: Processor \_PR_.P019 (ACPI ID 19) -> APIC ID 13 cpu18: on acpi0 cpu19: Processor \_PR_.P020 (ACPI ID 20) -> APIC ID 15 cpu19: on acpi0 cpu20: Processor \_PR_.P021 (ACPI ID 21) -> APIC ID 17 cpu20: on acpi0 cpu21: Processor \_PR_.P022 (ACPI ID 22) -> APIC ID 19 cpu21: on acpi0 cpu22: Processor \_PR_.P023 (ACPI ID 23) -> APIC ID 21 cpu22: on acpi0 cpu23: Processor \_PR_.P024 (ACPI ID 24) -> APIC ID 23 cpu23: on acpi0 ACPI: Processor \_PR_.P025 (ACPI ID 25) ignored ACPI: Processor \_PR_.P026 (ACPI ID 26) ignored ACPI: Processor \_PR_.P027 (ACPI ID 27) ignored ACPI: Processor \_PR_.P028 (ACPI ID 28) ignored ACPI: Processor \_PR_.P029 (ACPI ID 29) ignored ACPI: Processor \_PR_.P030 (ACPI ID 30) ignored ACPI: Processor \_PR_.P031 (ACPI ID 31) ignored ACPI: Processor \_PR_.P032 (ACPI ID 32) ignored attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 49 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 50 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 4 timers, legacy route hpet0: t0: irqs 0x00f00000 (0), 64bit, periodic hpet0: t1: irqs 0x00f00000 (0) hpet0: t2: irqs 0x00f00800 (0) hpet0: t3: irqs 0x00f01000 (0) Timecounter "HPET" frequency 14318180 Hz quality 950 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 51 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 ACPI timer: 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 5 Validation 0 5 N 0 5 After Disable 0 255 N 0 5 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 3 4 6 7 10 11 12 14 15 Validation 0 15 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 6 N 0 3 4 6 7 10 11 12 14 15 Validation 0 6 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 3 4 6 7 10 11 12 14 15 Validation 0 7 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 14 N 0 3 4 6 7 10 11 12 14 15 Validation 0 14 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pcib0: decoding 4 range 0-0xca1 pcib0: decoding 4 range 0xca4-0xcf7 pcib0: decoding 4 range 0xd00-0xffff pcib0: decoding 3 range 0xa0000-0xbffff pcib0: decoding 3 range 0xd0000-0xdffff pcib0: decoding 3 range 0xc0000000-0xdfffffff pcib0: decoding 3 range 0xf0000000-0xfed8ffff pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x3403, revid=0x22 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0140, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x3408, revid=0x22 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x340a, revid=0x22 domain=0, bus=0, slot=3, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x340e, revid=0x22 domain=0, bus=0, slot=7, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x3410, revid=0x22 domain=0, bus=0, slot=9, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x342d, revid=0x22 domain=0, bus=0, slot=19, func=0 class=08-00-20, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfec8a000, size 12, enabled pcib0: allocated type 3 (0xfec8a000-0xfec8afff) for rid 10 of pci0:0:19:0 found-> vendor=0x8086, dev=0x342e, revid=0x22 domain=0, bus=0, slot=20, func=0 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3422, revid=0x22 domain=0, bus=0, slot=20, func=1 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3423, revid=0x22 domain=0, bus=0, slot=20, func=2 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3438, revid=0x22 domain=0, bus=0, slot=20, func=3 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3a37, revid=0x00 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=14 map[20]: type I/O Port, range 32, base 0xbc00, size 5, enabled pcib0: allocated type 4 (0xbc00-0xbc1f) for rid 20 of pci0:0:26:0 pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x3a38, revid=0x00 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 map[20]: type I/O Port, range 32, base 0xb880, size 5, enabled pcib0: allocated type 4 (0xb880-0xb89f) for rid 20 of pci0:0:26:1 pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 22 found-> vendor=0x8086, dev=0x3a39, revid=0x00 domain=0, bus=0, slot=26, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=6 map[20]: type I/O Port, range 32, base 0xb800, size 5, enabled pcib0: allocated type 4 (0xb800-0xb81f) for rid 20 of pci0:0:26:2 pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 21 found-> vendor=0x8086, dev=0x3a3c, revid=0x00 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0146, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xdf3d6000, size 10, enabled pcib0: allocated type 3 (0xdf3d6000-0xdf3d63ff) for rid 10 of pci0:0:26:7 pcib0: matched entry for 0.26.INTD pcib0: slot 26 INTD hardwired to IRQ 20 found-> vendor=0x8086, dev=0x3a40, revid=0x00 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x3a34, revid=0x00 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=14 map[20]: type I/O Port, range 32, base 0xb480, size 5, enabled pcib0: allocated type 4 (0xb480-0xb49f) for rid 20 of pci0:0:29:0 pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x3a35, revid=0x00 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 map[20]: type I/O Port, range 32, base 0xb400, size 5, enabled pcib0: allocated type 4 (0xb400-0xb41f) for rid 20 of pci0:0:29:1 pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 22 found-> vendor=0x8086, dev=0x3a36, revid=0x00 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=6 map[20]: type I/O Port, range 32, base 0x7c00, size 5, enabled pcib0: allocated type 4 (0x7c00-0x7c1f) for rid 20 of pci0:0:29:2 pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 21 found-> vendor=0x8086, dev=0x3a3a, revid=0x00 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0146, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=14 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xdf3d4000, size 10, enabled pcib0: allocated type 3 (0xdf3d4000-0xdf3d43ff) for rid 10 of pci0:0:29:7 pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0x90 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x1b (6750 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3a16, revid=0x00 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0147, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3a20, revid=0x00 domain=0, bus=0, slot=31, func=2 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0045, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 3 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0x7880, size 3, enabled pcib0: allocated type 4 (0x7880-0x7887) for rid 10 of pci0:0:31:2 map[14]: type I/O Port, range 32, base 0x7800, size 2, enabled pcib0: allocated type 4 (0x7800-0x7803) for rid 14 of pci0:0:31:2 map[18]: type I/O Port, range 32, base 0x7480, size 3, enabled pcib0: allocated type 4 (0x7480-0x7487) for rid 18 of pci0:0:31:2 map[1c]: type I/O Port, range 32, base 0x7400, size 2, enabled pcib0: allocated type 4 (0x7400-0x7403) for rid 1c of pci0:0:31:2 map[20]: type I/O Port, range 32, base 0x7080, size 4, enabled pcib0: allocated type 4 (0x7080-0x708f) for rid 20 of pci0:0:31:2 map[24]: type I/O Port, range 32, base 0x7000, size 4, enabled pcib0: allocated type 4 (0x7000-0x700f) for rid 24 of pci0:0:31:2 pcib0: matched entry for 0.31.INTA pcib0: slot 31 INTA hardwired to IRQ 18 found-> vendor=0x8086, dev=0x3a30, revid=0x00 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0103, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[10]: type Memory, range 64, base 0xdf3d2000, size 8, enabled pcib0: allocated type 3 (0xdf3d2000-0xdf3d20ff) for rid 10 of pci0:0:31:3 map[20]: type I/O Port, range 32, base 0x400, size 5, enabled pcib0: allocated type 4 (0x400-0x41f) for rid 20 of pci0:0:31:3 pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x3a26, revid=0x00 domain=0, bus=0, slot=31, func=5 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0045, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=15 powerspec 3 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0x6880, size 3, enabled pcib0: allocated type 4 (0x6880-0x6887) for rid 10 of pci0:0:31:5 map[14]: type I/O Port, range 32, base 0x6800, size 2, enabled pcib0: allocated type 4 (0x6800-0x6803) for rid 14 of pci0:0:31:5 map[18]: type I/O Port, range 32, base 0x6480, size 3, enabled pcib0: allocated type 4 (0x6480-0x6487) for rid 18 of pci0:0:31:5 map[1c]: type I/O Port, range 32, base 0x6400, size 2, enabled pcib0: allocated type 4 (0x6400-0x6403) for rid 1c of pci0:0:31:5 map[20]: type I/O Port, range 32, base 0x6080, size 4, enabled pcib0: allocated type 4 (0x6080-0x608f) for rid 20 of pci0:0:31:5 map[24]: type I/O Port, range 32, base 0x6000, size 4, enabled pcib0: allocated type 4 (0x6000-0x600f) for rid 24 of pci0:0:31:5 pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 pcib1: at device 1.0 on pci0 pcib0: allocated type 4 (0x8000-0x8fff) for rid 1c of pcib1 pcib0: allocated type 3 (0xdf200000-0xdf2fffff) for rid 20 of pcib1 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x8000-0x8fff pcib1: memory decode 0xdf200000-0xdf2fffff pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x1000, dev=0x0072, revid=0x03 domain=0, bus=1, slot=0, func=0 class=01-07-00, hdrtype=0x00, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 15 messages in map 0x14 map[10]: type I/O Port, range 32, base 0x8000, size 8, enabled pcib1: allocated I/O port range (0x8000-0x80ff) for rid 10 of pci0:1:0:0 map[14]: type Memory, range 64, base 0xdf23c000, size 14, enabled pcib1: allocated memory range (0xdf23c000-0xdf23ffff) for rid 14 of pci0:1:0:0 map[1c]: type Memory, range 64, base 0xdf240000, size 18, enabled pcib1: allocated memory range (0xdf240000-0xdf27ffff) for rid 1c of pci0:1:0:0 pcib1: matched entry for 1.0.INTA pcib1: slot 0 INTA hardwired to IRQ 28 mps0: port 0x8000-0x80ff mem 0xdf23c000-0xdf23ffff,0xdf240000-0xdf27ffff irq 28 at device 0.0 on pci1 mps0: Firmware: 07.00.00.00, Driver: 16.00.00.00-fbsd mps0: IOCCapabilities: 185c mps0: attempting to allocate 1 MSI-X vectors (15 supported) msi: routing MSI-X IRQ 256 to local APIC 0 vector 52 mps0: using IRQ 256 for MSI-X pcib2: at device 3.0 on pci0 pcib0: allocated type 4 (0x9000-0x9fff) for rid 1c of pcib2 pcib0: allocated type 3 (0xdee00000-0xdeffffff) for rid 24 of pcib2 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x9000-0x9fff pcib2: prefetched decode 0xdee00000-0xdeffffff pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x8086, dev=0x10fb, revid=0x01 domain=0, bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit, vector masks MSI-X supports 64 messages in map 0x20 map[10]: type Prefetchable Memory, range 64, base 0xdef80000, size 19, enabled pcib2: allocated prefetch range (0xdef80000-0xdeffffff) for rid 10 of pci0:2:0:0 map[18]: type I/O Port, range 32, base 0x9c00, size 5, enabled pcib2: allocated I/O port range (0x9c00-0x9c1f) for rid 18 of pci0:2:0:0 map[20]: type Prefetchable Memory, range 64, base 0xdef7c000, size 14, enabled pcib2: allocated prefetch range (0xdef7c000-0xdef7ffff) for rid 20 of pci0:2:0:0 pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 24 found-> vendor=0x8086, dev=0x10fb, revid=0x01 domain=0, bus=2, slot=0, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit, vector masks MSI-X supports 64 messages in map 0x20 map[10]: type Prefetchable Memory, range 64, base 0xdee80000, size 19, enabled pcib2: allocated prefetch range (0xdee80000-0xdeefffff) for rid 10 of pci0:2:0:1 map[18]: type I/O Port, range 32, base 0x9880, size 5, enabled pcib2: allocated I/O port range (0x9880-0x989f) for rid 18 of pci0:2:0:1 map[20]: type Prefetchable Memory, range 64, base 0xdee7c000, size 14, enabled pcib2: allocated prefetch range (0xdee7c000-0xdee7ffff) for rid 20 of pci0:2:0:1 pcib2: matched entry for 2.0.INTB pcib2: slot 0 INTB hardwired to IRQ 34 ix0: port 0x9c00-0x9c1f mem 0xdef80000-0xdeffffff,0xdef7c000-0xdef7ffff irq 24 at device 0.0 on pci2 ix0: attempting to allocate 9 MSI-X vectors (64 supported) msi: routing MSI-X IRQ 257 to local APIC 0 vector 53 msi: routing MSI-X IRQ 258 to local APIC 0 vector 54 msi: routing MSI-X IRQ 259 to local APIC 0 vector 55 msi: routing MSI-X IRQ 260 to local APIC 0 vector 56 msi: routing MSI-X IRQ 261 to local APIC 0 vector 57 msi: routing MSI-X IRQ 262 to local APIC 0 vector 58 msi: routing MSI-X IRQ 263 to local APIC 0 vector 59 msi: routing MSI-X IRQ 264 to local APIC 0 vector 60 msi: routing MSI-X IRQ 265 to local APIC 0 vector 61 ix0: using IRQs 257-265 for MSI-X ix0: Using MSIX interrupts with 9 vectors ix0: bpf attached ix0: Ethernet address: 04:7d:7b:a5:87:32 ix0: PCI Express Bus: Speed 5.0GT/s Width x4 ix1: port 0x9880-0x989f mem 0xdee80000-0xdeefffff,0xdee7c000-0xdee7ffff irq 34 at device 0.1 on pci2 ix1: attempting to allocate 9 MSI-X vectors (64 supported) msi: routing MSI-X IRQ 266 to local APIC 0 vector 62 msi: routing MSI-X IRQ 267 to local APIC 0 vector 63 msi: routing MSI-X IRQ 268 to local APIC 0 vector 64 msi: routing MSI-X IRQ 269 to local APIC 0 vector 65 msi: routing MSI-X IRQ 270 to local APIC 0 vector 66 msi: routing MSI-X IRQ 271 to local APIC 0 vector 67 msi: routing MSI-X IRQ 272 to local APIC 0 vector 68 msi: routing MSI-X IRQ 273 to local APIC 0 vector 69 msi: routing MSI-X IRQ 274 to local APIC 0 vector 70 ix1: using IRQs 266-274 for MSI-X ix1: Using MSIX interrupts with 9 vectors ix1: bpf attached ix1: Ethernet address: 04:7d:7b:a5:87:33 ix1: PCI Express Bus: Speed 5.0GT/s Width x4 pcib3: at device 7.0 on pci0 pcib0: allocated type 4 (0xa000-0xafff) for rid 1c of pcib3 pcib0: allocated type 3 (0xdf400000-0xdf4fffff) for rid 20 of pcib3 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xa000-0xafff pcib3: memory decode 0xdf400000-0xdf4fffff pcib3: no prefetched decode pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x1000, dev=0x0064, revid=0x02 domain=0, bus=3, slot=0, func=0 class=01-07-00, hdrtype=0x00, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 15 messages in map 0x14 map[10]: type I/O Port, range 32, base 0xa000, size 8, enabled pcib3: allocated I/O port range (0xa000-0xa0ff) for rid 10 of pci0:3:0:0 map[14]: type Memory, range 64, base 0xdf43c000, size 14, enabled pcib3: allocated memory range (0xdf43c000-0xdf43ffff) for rid 14 of pci0:3:0:0 map[1c]: type Memory, range 64, base 0xdf440000, size 18, enabled pcib3: allocated memory range (0xdf440000-0xdf47ffff) for rid 1c of pci0:3:0:0 pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 30 mps1: port 0xa000-0xa0ff mem 0xdf43c000-0xdf43ffff,0xdf440000-0xdf47ffff irq 30 at device 0.0 on pci3 mps1: Firmware: 07.00.00.00, Driver: 16.00.00.00-fbsd mps1: IOCCapabilities: 1285c mps1: attempting to allocate 1 MSI-X vectors (15 supported) msi: routing MSI-X IRQ 275 to local APIC 0 vector 71 mps1: using IRQ 275 for MSI-X pcib4: at device 9.0 on pci0 pcib0: allocated type 4 (0xc000-0xcfff) for rid 1c of pcib4 pcib0: allocated type 3 (0xdf500000-0xdf5fffff) for rid 20 of pcib4 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0xc000-0xcfff pcib4: memory decode 0xdf500000-0xdf5fffff pcib4: no prefetched decode pci4: on pcib4 pci4: domain=0, physical bus=4 found-> vendor=0x1000, dev=0x0064, revid=0x02 domain=0, bus=4, slot=0, func=0 class=01-07-00, hdrtype=0x00, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 15 messages in map 0x14 map[10]: type I/O Port, range 32, base 0xc000, size 8, enabled pcib4: allocated I/O port range (0xc000-0xc0ff) for rid 10 of pci0:4:0:0 map[14]: type Memory, range 64, base 0xdf53c000, size 14, enabled pcib4: allocated memory range (0xdf53c000-0xdf53ffff) for rid 14 of pci0:4:0:0 map[1c]: type Memory, range 64, base 0xdf540000, size 18, enabled pcib4: allocated memory range (0xdf540000-0xdf57ffff) for rid 1c of pci0:4:0:0 pcib4: matched entry for 4.0.INTA pcib4: slot 0 INTA hardwired to IRQ 32 mps2: port 0xc000-0xc0ff mem 0xdf53c000-0xdf53ffff,0xdf540000-0xdf57ffff irq 32 at device 0.0 on pci4 mps2: Firmware: 07.00.00.00, Driver: 16.00.00.00-fbsd mps2: IOCCapabilities: 1285c mps2: attempting to allocate 1 MSI-X vectors (15 supported) msi: routing MSI-X IRQ 276 to local APIC 0 vector 72 mps2: using IRQ 276 for MSI-X pci0: at device 20.0 (no driver attached) pci0: at device 20.1 (no driver attached) pci0: at device 20.2 (no driver attached) pci0: at device 20.3 (no driver attached) uhci0: port 0xbc00-0xbc1f irq 23 at device 26.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 73 uhci0: LegSup = 0x2400 usbus0 on uhci0 usbus0: bpf attached uhci0: usbpf: Attached uhci1: port 0xb880-0xb89f irq 22 at device 26.1 on pci0 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 74 uhci1: LegSup = 0x2400 usbus1 on uhci1 usbus1: bpf attached uhci1: usbpf: Attached uhci2: port 0xb800-0xb81f irq 21 at device 26.2 on pci0 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 75 uhci2: LegSup = 0x2400 usbus2 on uhci2 usbus2: bpf attached uhci2: usbpf: Attached ehci0: mem 0xdf3d6000-0xdf3d63ff irq 20 at device 26.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 usbus3: bpf attached ehci0: usbpf: Attached pcib5: irq 17 at device 28.0 on pci0 pcib0: allocated type 4 (0xd000-0xdfff) for rid 1c of pcib5 pcib0: allocated type 3 (0xdf600000-0xdf6fffff) for rid 20 of pcib5 pcib5: domain 0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode 0xd000-0xdfff pcib5: memory decode 0xdf600000-0xdf6fffff pcib5: no prefetched decode pci5: on pcib5 pci5: domain=0, physical bus=5 found-> vendor=0x8086, dev=0x10c9, revid=0x01 domain=0, bus=5, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit, vector masks MSI-X supports 10 messages in map 0x1c map[10]: type Memory, range 32, base 0xdf6e0000, size 17, enabled pcib5: allocated memory range (0xdf6e0000-0xdf6fffff) for rid 10 of pci0:5:0:0 map[14]: type Memory, range 32, base 0xdf6c0000, size 17, enabled pcib5: allocated memory range (0xdf6c0000-0xdf6dffff) for rid 14 of pci0:5:0:0 map[18]: type I/O Port, range 32, base 0xdc00, size 5, enabled pcib5: allocated I/O port range (0xdc00-0xdc1f) for rid 18 of pci0:5:0:0 map[1c]: type Memory, range 32, base 0xdf69c000, size 14, enabled pcib5: allocated memory range (0xdf69c000-0xdf69ffff) for rid 1c of pci0:5:0:0 pcib5: matched entry for 5.0.INTA pcib5: slot 0 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x10c9, revid=0x01 domain=0, bus=5, slot=0, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit, vector masks MSI-X supports 10 messages in map 0x1c map[10]: type Memory, range 32, base 0xdf660000, size 17, enabled pcib5: allocated memory range (0xdf660000-0xdf67ffff) for rid 10 of pci0:5:0:1 map[14]: type Memory, range 32, base 0xdf640000, size 17, enabled pcib5: allocated memory range (0xdf640000-0xdf65ffff) for rid 14 of pci0:5:0:1 map[18]: type I/O Port, range 32, base 0xd880, size 5, enabled pcib5: allocated I/O port range (0xd880-0xd89f) for rid 18 of pci0:5:0:1 map[1c]: type Memory, range 32, base 0xdf61c000, size 14, enabled pcib5: allocated memory range (0xdf61c000-0xdf61ffff) for rid 1c of pci0:5:0:1 pcib5: matched entry for 5.0.INTB pcib5: slot 0 INTB hardwired to IRQ 17 igb0: port 0xdc00-0xdc1f mem 0xdf6e0000-0xdf6fffff,0xdf6c0000-0xdf6dffff,0xdf69c000-0xdf69ffff irq 16 at device 0.0 on pci5 igb0: attempting to allocate 9 MSI-X vectors (10 supported) msi: routing MSI-X IRQ 277 to local APIC 0 vector 76 msi: routing MSI-X IRQ 278 to local APIC 0 vector 77 msi: routing MSI-X IRQ 279 to local APIC 0 vector 78 msi: routing MSI-X IRQ 280 to local APIC 0 vector 79 msi: routing MSI-X IRQ 281 to local APIC 0 vector 80 msi: routing MSI-X IRQ 282 to local APIC 0 vector 81 msi: routing MSI-X IRQ 283 to local APIC 0 vector 82 msi: routing MSI-X IRQ 284 to local APIC 0 vector 83 msi: routing MSI-X IRQ 285 to local APIC 0 vector 84 igb0: using IRQs 277-285 for MSI-X igb0: Using MSIX interrupts with 9 vectors igb0: bpf attached igb0: Ethernet address: 04:7d:7b:a5:c5:c2 igb0: Bound queue 0 to cpu 0 igb0: Bound queue 1 to cpu 1 igb0: Bound queue 2 to cpu 2 igb0: Bound queue 3 to cpu 3 igb0: Bound queue 4 to cpu 4 igb0: Bound queue 5 to cpu 5 igb0: Bound queue 6 to cpu 6 igb0: Bound queue 7 to cpu 7 igb1: port 0xd880-0xd89f mem 0xdf660000-0xdf67ffff,0xdf640000-0xdf65ffff,0xdf61c000-0xdf61ffff irq 17 at device 0.1 on pci5 igb1: attempting to allocate 9 MSI-X vectors (10 supported) msi: routing MSI-X IRQ 286 to local APIC 0 vector 85 msi: routing MSI-X IRQ 287 to local APIC 0 vector 86 msi: routing MSI-X IRQ 288 to local APIC 0 vector 87 msi: routing MSI-X IRQ 289 to local APIC 0 vector 88 msi: routing MSI-X IRQ 290 to local APIC 0 vector 89 msi: routing MSI-X IRQ 291 to local APIC 0 vector 90 msi: routing MSI-X IRQ 292 to local APIC 0 vector 91 msi: routing MSI-X IRQ 293 to local APIC 0 vector 92 msi: routing MSI-X IRQ 294 to local APIC 0 vector 93 igb1: using IRQs 286-294 for MSI-X igb1: Using MSIX interrupts with 9 vectors igb1: bpf attached igb1: Ethernet address: 04:7d:7b:a5:c5:c3 igb1: Bound queue 0 to cpu 8 igb1: Bound queue 1 to cpu 9 igb1: Bound queue 2 to cpu 10 igb1: Bound queue 3 to cpu 11 igb1: Bound queue 4 to cpu 12 igb1: Bound queue 5 to cpu 13 igb1: Bound queue 6 to cpu 14 igb1: Bound queue 7 to cpu 15 uhci3: port 0xb480-0xb49f irq 23 at device 29.0 on pci0 uhci3: LegSup = 0x2400 usbus4 on uhci3 usbus4: bpf attached uhci3: usbpf: Attached uhci4: port 0xb400-0xb41f irq 22 at device 29.1 on pci0 uhci4: LegSup = 0x2400 usbus5 on uhci4 usbus5: bpf attached uhci4: usbpf: Attached uhci5: port 0x7c00-0x7c1f irq 21 at device 29.2 on pci0 uhci5: LegSup = 0x2400 usbus6 on uhci5 usbus6: bpf attached uhci5: usbpf: Attached ehci1: mem 0xdf3d4000-0xdf3d43ff irq 23 at device 29.7 on pci0 usbus7: EHCI version 1.0 usbus7 on ehci1 usbus7: bpf attached ehci1: usbpf: Attached pcib6: at device 30.0 on pci0 pcib0: allocated type 4 (0xe000-0xefff) for rid 1c of pcib6 pcib0: allocated type 3 (0xdf700000-0xdfffffff) for rid 20 of pcib6 pcib6: domain 0 pcib6: secondary bus 6 pcib6: subordinate bus 6 pcib6: I/O decode 0xe000-0xefff pcib6: memory decode 0xdf700000-0xdfffffff pcib6: no prefetched decode pcib6: Subtractively decoded bridge. pci6: on pcib6 pci6: domain=0, physical bus=6 found-> vendor=0x1a03, dev=0x2000, revid=0x10 domain=0, bus=6, slot=11, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xdf800000, size 23, enabled pcib6: allocated memory range (0xdf800000-0xdfffffff) for rid 10 of pci0:6:11:0 map[14]: type Memory, range 32, base 0xdf7e0000, size 17, enabled pcib6: allocated memory range (0xdf7e0000-0xdf7fffff) for rid 14 of pci0:6:11:0 map[18]: type I/O Port, range 32, base 0xec00, size 7, enabled pcib6: allocated I/O port range (0xec00-0xec7f) for rid 18 of pci0:6:11:0 pcib6: matched entry for 6.11.INTA pcib6: slot 11 INTA hardwired to IRQ 16 vgapci0: port 0xec00-0xec7f mem 0xdf800000-0xdfffffff,0xdf7e0000-0xdf7fffff irq 16 at device 11.0 on pci6 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x7880-0x7887,0x7800-0x7803,0x7480-0x7487,0x7400-0x7403,0x7080-0x708f,0x7000-0x700f irq 18 at device 31.2 on pci0 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 94 ata2: at channel 0 on atapci0 ata3: at channel 1 on atapci0 ichsmb0: port 0x400-0x41f mem 0xdf3d2000-0xdf3d20ff irq 18 at device 31.3 on pci0 smbus0: on ichsmb0 smb0: on smbus0 atapci1: port 0x6880-0x6887,0x6800-0x6803,0x6480-0x6487,0x6400-0x6403,0x6080-0x608f,0x6000-0x600f irq 19 at device 31.5 on pci0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 95 ata4: at channel 0 on atapci1 ata5: at channel 1 on atapci1 acpi_button0: on acpi0 ipmi0: port 0xca2-0xca3 on acpi0 ipmi0: KCS mode found at io 0xca2 on acpi uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 96 uart0: fast interrupt uart0: console (115200,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 ioapic0: routing intpin 3 (ISA IRQ 3) to lapic 0 vector 97 uart1: fast interrupt qpi0: on motherboard pcib7: pcibus 255 on qpi0 pci255: on pcib7 pci255: domain=0, physical bus=255 found-> vendor=0x8086, dev=0x2c70, revid=0x02 domain=0, bus=255, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d81, revid=0x02 domain=0, bus=255, slot=0, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d90, revid=0x02 domain=0, bus=255, slot=2, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d91, revid=0x02 domain=0, bus=255, slot=2, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d92, revid=0x02 domain=0, bus=255, slot=2, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d93, revid=0x02 domain=0, bus=255, slot=2, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d94, revid=0x02 domain=0, bus=255, slot=2, func=4 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d95, revid=0x02 domain=0, bus=255, slot=2, func=5 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d98, revid=0x02 domain=0, bus=255, slot=3, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d99, revid=0x02 domain=0, bus=255, slot=3, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d9a, revid=0x02 domain=0, bus=255, slot=3, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d9c, revid=0x02 domain=0, bus=255, slot=3, func=4 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2da0, revid=0x02 domain=0, bus=255, slot=4, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2da1, revid=0x02 domain=0, bus=255, slot=4, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2da2, revid=0x02 domain=0, bus=255, slot=4, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2da3, revid=0x02 domain=0, bus=255, slot=4, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2da8, revid=0x02 domain=0, bus=255, slot=5, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2da9, revid=0x02 domain=0, bus=255, slot=5, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2daa, revid=0x02 domain=0, bus=255, slot=5, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2dab, revid=0x02 domain=0, bus=255, slot=5, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2db0, revid=0x02 domain=0, bus=255, slot=6, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2db1, revid=0x02 domain=0, bus=255, slot=6, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2db2, revid=0x02 domain=0, bus=255, slot=6, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2db3, revid=0x02 domain=0, bus=255, slot=6, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pcib8: pcibus 254 on qpi0 pci254: on pcib8 pci254: domain=0, physical bus=254 found-> vendor=0x8086, dev=0x2c70, revid=0x02 domain=0, bus=254, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d81, revid=0x02 domain=0, bus=254, slot=0, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d90, revid=0x02 domain=0, bus=254, slot=2, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d91, revid=0x02 domain=0, bus=254, slot=2, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d92, revid=0x02 domain=0, bus=254, slot=2, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d93, revid=0x02 domain=0, bus=254, slot=2, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d94, revid=0x02 domain=0, bus=254, slot=2, func=4 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d95, revid=0x02 domain=0, bus=254, slot=2, func=5 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d98, revid=0x02 domain=0, bus=254, slot=3, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d99, revid=0x02 domain=0, bus=254, slot=3, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d9a, revid=0x02 domain=0, bus=254, slot=3, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d9c, revid=0x02 domain=0, bus=254, slot=3, func=4 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2da0, revid=0x02 domain=0, bus=254, slot=4, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2da1, revid=0x02 domain=0, bus=254, slot=4, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2da2, revid=0x02 domain=0, bus=254, slot=4, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2da3, revid=0x02 domain=0, bus=254, slot=4, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2da8, revid=0x02 domain=0, bus=254, slot=5, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2da9, revid=0x02 domain=0, bus=254, slot=5, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2daa, revid=0x02 domain=0, bus=254, slot=5, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2dab, revid=0x02 domain=0, bus=254, slot=5, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2db0, revid=0x02 domain=0, bus=254, slot=6, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2db1, revid=0x02 domain=0, bus=254, slot=6, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2db2, revid=0x02 domain=0, bus=254, slot=6, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2db3, revid=0x02 domain=0, bus=254, slot=6, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) acpi0: wakeup code va 0xffffff945aa36000 pa 0x90000 isab0: found ICH10 or equivalent chipset: Intel ICH10R watchdog timer pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 pcib0: allocated type 3 (0xd0000-0xd07ff) for rid 4 of orm0 pcib0: allocated type 3 (0xd0800-0xd0fff) for rid 4 of orm0 pcib0: allocated type 3 (0xd1000-0xd17ff) for rid 4 of orm0 pcib0: allocated type 3 (0xd1800-0xd1fff) for rid 4 of orm0 pcib0: allocated type 3 (0xd2000-0xd27ff) for rid 4 of orm0 pcib0: allocated type 3 (0xd2800-0xd2fff) for rid 4 of orm0 pcib0: allocated type 3 (0xd3000-0xd37ff) for rid 4 of orm0 pcib0: allocated type 3 (0xd3800-0xd3fff) for rid 4 of orm0 pcib0: allocated type 3 (0xd4000-0xd47ff) for rid 4 of orm0 pcib0: allocated type 3 (0xd4800-0xd4fff) for rid 4 of orm0 pcib0: allocated type 3 (0xd5000-0xd57ff) for rid 4 of orm0 pcib0: allocated type 3 (0xd5800-0xd5fff) for rid 4 of orm0 pcib0: allocated type 3 (0xd6000-0xd67ff) for rid 4 of orm0 pcib0: allocated type 3 (0xd6800-0xd6fff) for rid 4 of orm0 pcib0: allocated type 3 (0xd7000-0xd77ff) for rid 4 of orm0 pcib0: allocated type 3 (0xd7800-0xd7fff) for rid 4 of orm0 pcib0: allocated type 3 (0xd8000-0xd87ff) for rid 4 of orm0 pcib0: allocated type 3 (0xd8800-0xd8fff) for rid 4 of orm0 pcib0: allocated type 3 (0xd9000-0xd97ff) for rid 4 of orm0 pcib0: allocated type 3 (0xd9800-0xd9fff) for rid 4 of orm0 pcib0: allocated type 3 (0xda000-0xda7ff) for rid 4 of orm0 pcib0: allocated type 3 (0xda800-0xdafff) for rid 4 of orm0 pcib0: allocated type 3 (0xdb000-0xdb7ff) for rid 4 of orm0 pcib0: allocated type 3 (0xdb800-0xdbfff) for rid 4 of orm0 pcib0: allocated type 3 (0xdc000-0xdc7ff) for rid 4 of orm0 pcib0: allocated type 3 (0xdc800-0xdcfff) for rid 4 of orm0 pcib0: allocated type 3 (0xdd000-0xdd7ff) for rid 4 of orm0 pcib0: allocated type 3 (0xdd800-0xddfff) for rid 4 of orm0 pcib0: allocated type 3 (0xde000-0xde7ff) for rid 4 of orm0 pcib0: allocated type 3 (0xde800-0xdefff) for rid 4 of orm0 pcib0: allocated type 3 (0xdf000-0xdf7ff) for rid 4 of orm0 pcib0: allocated type 3 (0xdf800-0xdffff) for rid 4 of orm0 isa_probe_children: disabling PnP devices ichwd0 on isa0 isab0: found ICH10 or equivalent chipset: Intel ICH10R watchdog timer pcib0: allocated type 4 (0x830-0x837) for rid 0 of ichwd0 pcib0: allocated type 4 (0x860-0x87f) for rid 1 of ichwd0 pcib0: allocated type 3 (0xfed1f410-0xfed1f413) for rid 0 of isab0 ichwd0: ICH WDT present but disabled in BIOS or hardware device_attach: ichwd0 attach returned 6 ipmi1: on isa0 device_attach: ipmi1 attach returned 16 atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it uart: uart1 already exists; skipping it isa_probe_children: probing non-PnP devices ichwd0 at port 0x830-0x837,0x860-0x87f on isa0 isab0: found ICH10 or equivalent chipset: Intel ICH10R watchdog timer pcib0: allocated type 4 (0x830-0x837) for rid 0 of ichwd0 pcib0: allocated type 4 (0x860-0x87f) for rid 1 of ichwd0 pcib0: allocated type 3 (0xfed1f410-0xfed1f413) for rid 0 of isab0 ichwd0: ICH WDT present but disabled in BIOS or hardware device_attach: ichwd0 attach returned 6 ipmi1: on isa0 device_attach: ipmi1 attach returned 16 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xcd7ff,0xcd800-0xce7ff,0xce800-0xcf7ff on isa0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa sc0: at flags 0x100 on isa0 sc0: CGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3d0-0x3db iomem 0xb8000-0xbffff on isa0 pcib0: allocated type 4 (0x3d0-0x3db) for rid 0 of vga0 pcib0: allocated type 3 (0xb8000-0xbffff) for rid 0 of vga0 pcib0: allocated type 4 (0x60-0x60) for rid 0 of atkbdc0 pcib0: allocated type 4 (0x64-0x64) for rid 1 of atkbdc0 atkbdc0: at port 0x60,0x64 on isa0 pcib0: allocated type 4 (0x60-0x60) for rid 0 of atkbdc0 pcib0: allocated type 4 (0x64-0x64) for rid 1 of atkbdc0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 98 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 wbwd0 failed to probe on isa0 isa_probe_children: probing PnP devices coretemp0: on cpu0 coretemp0: Setting TjMax=96 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 coretemp1: Setting TjMax=96 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 coretemp2: Setting TjMax=96 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 coretemp3: Setting TjMax=96 est3: on cpu3 p4tcc3: on cpu3 coretemp4: on cpu4 coretemp4: Setting TjMax=96 est4: on cpu4 p4tcc4: on cpu4 coretemp5: on cpu5 coretemp5: Setting TjMax=96 est5: on cpu5 p4tcc5: on cpu5 coretemp6: on cpu6 coretemp6: Setting TjMax=96 est6: on cpu6 p4tcc6: on cpu6 coretemp7: on cpu7 coretemp7: Setting TjMax=96 est7: on cpu7 p4tcc7: on cpu7 coretemp8: on cpu8 coretemp8: Setting TjMax=96 est8: on cpu8 p4tcc8: on cpu8 coretemp9: on cpu9 coretemp9: Setting TjMax=96 est9: on cpu9 p4tcc9: on cpu9 coretemp10: on cpu10 coretemp10: Setting TjMax=96 est10: on cpu10 p4tcc10: on cpu10 coretemp11: on cpu11 coretemp11: Setting TjMax=96 est11: on cpu11 p4tcc11: on cpu11 coretemp12: on cpu12 coretemp12: Setting TjMax=96 est12: on cpu12 p4tcc12: on cpu12 coretemp13: on cpu13 coretemp13: Setting TjMax=96 est13: on cpu13 p4tcc13: on cpu13 coretemp14: on cpu14 coretemp14: Setting TjMax=96 est14: on cpu14 p4tcc14: on cpu14 coretemp15: on cpu15 coretemp15: Setting TjMax=96 est15: on cpu15 p4tcc15: on cpu15 coretemp16: on cpu16 coretemp16: Setting TjMax=96 est16: on cpu16 p4tcc16: on cpu16 coretemp17: on cpu17 coretemp17: Setting TjMax=96 est17: on cpu17 p4tcc17: on cpu17 coretemp18: on cpu18 coretemp18: Setting TjMax=96 est18: on cpu18 p4tcc18: on cpu18 coretemp19: on cpu19 coretemp19: Setting TjMax=96 est19: on cpu19 p4tcc19: on cpu19 coretemp20: on cpu20 coretemp20: Setting TjMax=96 est20: on cpu20 p4tcc20: on cpu20 coretemp21: on cpu21 coretemp21: Setting TjMax=96 est21: on cpu21 p4tcc21: on cpu21 coretemp22: on cpu22 coretemp22: Setting TjMax=96 est22: on cpu22 p4tcc22: on cpu22 coretemp23: on cpu23 coretemp23: Setting TjMax=96 est23: on cpu23 p4tcc23: on cpu23 Device configuration finished. ZFS filesystem version: 5 ZFS storage pool version: features support (5000) lapic: Divisor 2, Frequency 66670376 Hz Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining crypto: ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to accept, logging disabled ipfw0: bpf attached lo0: bpf attached usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered ata2: SATA reset: ports status=0x00 ata2: p0: SATA connect timeout status=00000000 ata2: p1: SATA connect timeout status=00000000 ipmi0: IPMI device rev. 1, firmware rev. 1.03, version 2.0 ata3: SATA reset: ports status=0x00 ata3: p0: SATA connect timeout status=00000000 ata3: p1: SATA connect timeout status=00000000 ipmi0: Number of channels 2 ipmi0: Attached watchdog uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered ata4: SATA reset: ports status=0x00 ata4: p0: SATA connect timeout status=00000000 ugen3.2: at usbus3 uhub8: on usbus3 ata5: SATA reset: ports status=0x00 ata5: p0: SATA connect timeout status=00000000 (probe0:mps0:0:11:0): Down reving Protocol Version from 4 to 0? (probe1:mps0:0:12:0): Down reving Protocol Version from 4 to 0? (probe2:mps0:0:13:0): Down reving Protocol Version from 4 to 0? (probe3:mps0:0:14:0): Down reving Protocol Version from 4 to 0? uhub8: 3 ports with 3 removable, self powered (probe4:mps0:0:15:0): Down reving Protocol Version from 4 to 0? (probe5:mps0:0:16:0): Down reving Protocol Version from 4 to 0? failure at /usr/src-9-stable/sys/dev/mps/mps_sas_lsi.c:667/mpssas_add_device()! Could not get ID for device with handle 0x0010 mpssas_fw_work: failed to add device with handle 0x10 (probe6:mps2:0:16:0): Down reving Protocol Version from 4 to 0? (probe7:mps1:0:16:0): Down reving Protocol Version from 4 to 0? (probe8:mps2:0:17:0): Down reving Protocol Version from 4 to 0? (probe9:mps1:0:17:0): Down reving Protocol Version from 4 to 0? (probe10:mps2:0:18:0): Down reving Protocol Version from 4 to 0? (probe11:mps1:0:18:0): Down reving Protocol Version from 4 to 0? (probe12:mps2:0:19:0): Down reving Protocol Version from 4 to 0? (probe13:mps1:0:19:0): Down reving Protocol Version from 4 to 0? (probe14:mps2:0:20:0): Down reving Protocol Version from 4 to 0? (probe15:mps1:0:20:0): Down reving Protocol Version from 4 to 0? (probe16:mps2:0:21:0): Down reving Protocol Version from 4 to 0? (probe17:mps1:0:21:0): Down reving Protocol Version from 4 to 0? (probe18:mps2:0:22:0): Down reving Protocol Version from 4 to 0? (probe19:mps1:0:22:0): Down reving Protocol Version from 4 to 0? (probe20:mps2:0:23:0): Down reving Protocol Version from 4 to 0? (probe21:mps1:0:23:0): Down reving Protocol Version from 4 to 0? (probe22:mps2:0:24:0): Down reving Protocol Version from 4 to 0? (probe23:mps1:0:24:0): Down reving Protocol Version from 4 to 0? (probe24:mps2:0:25:0): Down reving Protocol Version from 4 to 0? (probe25:mps1:0:25:0): Down reving Protocol Version from 4 to 0? (probe26:mps2:0:26:0): Down reving Protocol Version from 4 to 0? (probe27:mps1:0:26:0): Down reving Protocol Version from 4 to 0? (probe28:mps2:0:27:0): Down reving Protocol Version from 4 to 0? (probe29:mps1:0:27:0): Down reving Protocol Version from 4 to 0? (probe30:mps2:0:28:0): Down reving Protocol Version from 4 to 0? (probe31:mps1:0:28:0): Down reving Protocol Version from 4 to 0? (probe32:mps2:0:29:0): Down reving Protocol Version from 4 to 0? (probe33:mps1:0:29:0): Down reving Protocol Version from 4 to 0? (probe34:mps2:0:30:0): Down reving Protocol Version from 4 to 0? (probe35:mps1:0:30:0): Down reving Protocol Version from 4 to 0? (probe36:mps2:0:31:0): Down reving Protocol Version from 4 to 0? (probe37:mps1:0:31:0): Down reving Protocol Version from 4 to 0? (probe38:mps2:0:32:0): Down reving Protocol Version from 4 to 0? (probe39:mps1:0:32:0): Down reving Protocol Version from 4 to 0? (probe40:mps2:0:33:0): Down reving Protocol Version from 4 to 0? Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff804ce7f9 stack pointer = 0x28:0xffffff945a7fe9e0 frame pointer = 0x28:0xffffff945a7fe9f0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 15 (usbus6) [ thread pid 15 tid 100177 ] Stopped at usbd_get_hr_func+0x29: movq 0x4f0(%rdx),%rax db> bt Tracing pid 15 tid 100177 td 0xfffffe000fb9e490 usbd_get_hr_func() at usbd_get_hr_func+0x29/frame 0xffffff945a7fe9f0 usbd_do_request_flags() at usbd_do_request_flags+0x18e/frame 0xffffff945a7feaa0 usbd_req_get_port_status() at usbd_req_get_port_status+0x43/frame 0xffffff945a7fead0 uhub_read_port_status() at uhub_read_port_status+0x2d/frame 0xffffff945a7feb10 uhub_explore() at uhub_explore+0xc5/frame 0xffffff945a7feb80 usb_bus_explore() at usb_bus_explore+0xcb/frame 0xffffff945a7febb0 usb_process() at usb_process+0xd3/frame 0xffffff945a7febe0 fork_exit() at fork_exit+0x11f/frame 0xffffff945a7fec30 fork_trampoline() at fork_trampoline+0xe/frame 0xffffff945a7fec30 --- trap 0, rip = 0, rsp = 0xffffff945a7fecf0, rbp = 0 --- I think usbd_get_hr_func() is just an innocent bystander here, although it's odd how consistent the crash is. A verbose boot from 9.2, where it works, is available on request. From owner-freebsd-scsi@FreeBSD.ORG Wed Jan 29 18:59:27 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4AF9D465; Wed, 29 Jan 2014 18:59:27 +0000 (UTC) Received: from mta05.bitpro.no (mta05.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 0189C19CA; Wed, 29 Jan 2014 18:59:26 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta05.bitpro.no (Postfix) with ESMTPS id F0EFA17FC8D; Wed, 29 Jan 2014 19:59:18 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id E72EF8F81BD; Wed, 29 Jan 2014 20:00:10 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kdl8Y78qmjWZ; Wed, 29 Jan 2014 20:00:10 +0100 (CET) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id 1517E8F81AD; Wed, 29 Jan 2014 20:00:10 +0100 (CET) Message-ID: <52E94FC2.1010901@bitfrost.no> Date: Wed, 29 Jan 2014 20:00:18 +0100 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Garrett Wollman , freebsd-stable@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: stable/9 mps(4) rev 254938 == BOOM! References: <21225.19508.683025.581620@khavrinen.csail.mit.edu> In-Reply-To: <21225.19508.683025.581620@khavrinen.csail.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: scottl@freebsd.org, ken@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 18:59:27 -0000 On 01/29/14 19:45, Garrett Wollman wrote: > I've been trying to puzzle out why the USB stack hits a GPF during > boot on 9-stable on one of my machines (which runs 9.2 just fine), and > by trial and error I've found that it is actually caused by r254938, > which is a mega-MFC of mps(4) driver changes, even though the fault > always occurs at the same place in a harmless USB subroutine. Details > below; config available on request. > > -GAWollman Hi, To me this sounds like someone is writing outside their assigned area. options DEBUG_REDZONE Maybe some change that should have been MFC'ed did not get MFC'ed. I think you can copy the mps driver from -current just keeping the following deltas intact: - - if (curthread->td_no_sleeping != 0) + + if(curthread->td_pflags & TDP_NOSLEEPING) sleep_flags = NO_SLEEP; --HPS From owner-freebsd-scsi@FreeBSD.ORG Wed Jan 29 21:37:18 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C786B21F; Wed, 29 Jan 2014 21:37:18 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 803CF1826; Wed, 29 Jan 2014 21:37:18 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s0TLbDKS006717; Wed, 29 Jan 2014 16:37:13 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id s0TLbD5G006716; Wed, 29 Jan 2014 16:37:13 -0500 (EST) (envelope-from wollman) Date: Wed, 29 Jan 2014 16:37:13 -0500 (EST) Message-Id: <201401292137.s0TLbD5G006716@hergotha.csail.mit.edu> From: wollman@csail.mit.edu To: hps@bitfrost.no Subject: Heap overflow in mps(4) (was: Re: stable/9 mps(4) rev 254938 == BOOM!) In-Reply-To: <52E94FC2.1010901@bitfrost.no> References: <21225.19508.683025.581620@khavrinen.csail.mit.edu> Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Wed, 29 Jan 2014 16:37:13 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: freebsd-scsi@freebsd.org, ken@freebsd.org, scottl@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 21:37:18 -0000 In article <52E94FC2.1010901@bitfrost.no>, hps@bitfrost.no writes: >To me this sounds like someone is writing outside their assigned area. > >options DEBUG_REDZONE hselasky@ nails it! The mps(4) changes in stable/9 r254938 reliably cause a GPF during boot in non-debugging kernels, but adding DEBUG_REDZONE is sufficient to prevent the fault. Whichever heap allocation is being overrun does *not* ever get freed: there are no redzone messages on the console. (It also boots much faster with the new probing code, which is certainly a plus for debugging.) I can confirm that the tip of stable/9 (r261256) also works with DEBUG_REDZONE and fails without it. Only trouble is that I need to do performance testing, which DEBUG_REDZONE is not exactly going to help with. -GAWollman From owner-freebsd-scsi@FreeBSD.ORG Wed Jan 29 22:16:45 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48AF654D; Wed, 29 Jan 2014 22:16:45 +0000 (UTC) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 09AE71B41; Wed, 29 Jan 2014 22:16:43 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id s0TMFEhD048604; Wed, 29 Jan 2014 15:15:14 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id s0TMFEMR048603; Wed, 29 Jan 2014 15:15:14 -0700 (MST) (envelope-from ken) Date: Wed, 29 Jan 2014 15:15:14 -0700 From: "Kenneth D. Merry" To: wollman@csail.mit.edu Subject: Re: Heap overflow in mps(4) (was: Re: stable/9 mps(4) rev 254938 == BOOM!) Message-ID: <20140129221514.GA47535@nargothrond.kdm.org> References: <21225.19508.683025.581620@khavrinen.csail.mit.edu> <201401292137.s0TLbD5G006716@hergotha.csail.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201401292137.s0TLbD5G006716@hergotha.csail.mit.edu> User-Agent: Mutt/1.4.2i Cc: hps@bitfrost.no, freebsd-scsi@freebsd.org, scottl@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 22:16:45 -0000 On Wed, Jan 29, 2014 at 16:37:13 -0500, wollman@csail.mit.edu wrote: > In article <52E94FC2.1010901@bitfrost.no>, hps@bitfrost.no writes: > >To me this sounds like someone is writing outside their assigned area. > > > >options DEBUG_REDZONE > > hselasky@ nails it! The mps(4) changes in stable/9 r254938 reliably > cause a GPF during boot in non-debugging kernels, but adding > DEBUG_REDZONE is sufficient to prevent the fault. Whichever heap > allocation is being overrun does *not* ever get freed: there are no > redzone messages on the console. (It also boots much faster with the > new probing code, which is certainly a plus for debugging.) > > I can confirm that the tip of stable/9 (r261256) also works with > DEBUG_REDZONE and fails without it. Only trouble is that I need to do > performance testing, which DEBUG_REDZONE is not exactly going to help > with. Hmm. What does vmstat -m show for the mps malloc bucket? Are you booting off of the controller? If not, could you try building mps as a module and unloading it? Perhaps the memory would get freed when the module is unloaded and the redzone code would show where the problem is. How many drives do you have in the system, and how many of them are SAS vs. SATA? I haven't seen this problem, but it may be that we've gotten lucky or don't have the particular set of factors that you have. We have tested with more than 200 drives connected, but they were all SAS. I'll take a look and see if I can see anything that looks suspicious. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Wed Jan 29 22:47:54 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 782B05F3; Wed, 29 Jan 2014 22:47:54 +0000 (UTC) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [IPv6:2001:470:8b2d:1e1c:21b:21ff:feb8:d7b0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2AE671EDB; Wed, 29 Jan 2014 22:47:54 +0000 (UTC) Received: from khavrinen.csail.mit.edu (localhost [127.0.0.1]) by khavrinen.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s0TMlq0a049321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL CN=khavrinen.csail.mit.edu issuer=Client+20CA); Wed, 29 Jan 2014 17:47:53 -0500 (EST) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.14.7/8.14.7/Submit) id s0TMlqfF049318; Wed, 29 Jan 2014 17:47:52 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21225.34072.966571.408714@khavrinen.csail.mit.edu> Date: Wed, 29 Jan 2014 17:47:52 -0500 From: Garrett Wollman To: "Kenneth D. Merry" Subject: Re: Heap overflow in mps(4) (was: Re: stable/9 mps(4) rev 254938 == BOOM!) In-Reply-To: <20140129221514.GA47535@nargothrond.kdm.org> References: <21225.19508.683025.581620@khavrinen.csail.mit.edu> <201401292137.s0TLbD5G006716@hergotha.csail.mit.edu> <20140129221514.GA47535@nargothrond.kdm.org> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (khavrinen.csail.mit.edu [127.0.0.1]); Wed, 29 Jan 2014 17:47:53 -0500 (EST) Cc: freebsd-scsi@freebsd.org, scottl@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 22:47:54 -0000 < said: > Hmm. What does vmstat -m show for the mps malloc bucket? mps 237 1996K - 1005 512,1024,2048 One of these is probably getting corrupted: USBdev 44 23K - 44 512,1024 USB 75 154K - 78 512,4096 (The 512 and 1024 would ultimately come out of the same page for either malloc type.) > Are you booting off of the controller? Yes, all the storage controllers in this machine are mps. (There's SATA on the motherboard but it's not wired to anything.) > How many drives do you have in the system, and how many of them are SAS vs. > SATA? 98 drives, of which 92 are dual-pathed, all SAS, for a total of 198 da(4) instances. Thanks for taking a look... I'm happy to try adding some additional debugging if it would be helpful. -GAWollman From owner-freebsd-scsi@FreeBSD.ORG Thu Jan 30 00:05:51 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A98F77A; Thu, 30 Jan 2014 00:05:51 +0000 (UTC) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [IPv6:2001:470:8b2d:1e1c:21b:21ff:feb8:d7b0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 04BC917EE; Thu, 30 Jan 2014 00:05:50 +0000 (UTC) Received: from khavrinen.csail.mit.edu (localhost [127.0.0.1]) by khavrinen.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s0U05n0R049891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL CN=khavrinen.csail.mit.edu issuer=Client+20CA); Wed, 29 Jan 2014 19:05:49 -0500 (EST) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.14.7/8.14.7/Submit) id s0U05nVd049888; Wed, 29 Jan 2014 19:05:49 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21225.38749.179621.454579@khavrinen.csail.mit.edu> Date: Wed, 29 Jan 2014 19:05:49 -0500 From: Garrett Wollman To: "Kenneth D. Merry" Subject: Re: Heap overflow in mps(4) (was: Re: stable/9 mps(4) rev 254938 == BOOM!) In-Reply-To: <20140129221514.GA47535@nargothrond.kdm.org> References: <21225.19508.683025.581620@khavrinen.csail.mit.edu> <201401292137.s0TLbD5G006716@hergotha.csail.mit.edu> <20140129221514.GA47535@nargothrond.kdm.org> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (khavrinen.csail.mit.edu [127.0.0.1]); Wed, 29 Jan 2014 19:05:49 -0500 (EST) Cc: freebsd-scsi@freebsd.org, scottl@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 00:05:51 -0000 < said: > Are you booting off of the controller? If not, could you try building mps > as a module and unloading it? Perhaps the memory would get freed when the > module is unloaded and the redzone code would show where the problem is. I built a memory-stick image and tried this. No redzone messages, but the driver leaks 18 allocations (142336 bytes). -GAWollman From owner-freebsd-scsi@FreeBSD.ORG Thu Jan 30 22:21:43 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0F99756 for ; Thu, 30 Jan 2014 22:21:42 +0000 (UTC) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 98E1E1D2B for ; Thu, 30 Jan 2014 22:21:42 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id i17so5953148qcy.39 for ; Thu, 30 Jan 2014 14:21:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=r6hZhqojbYF80e/6udxqIkMtGf5ruc+nIp4DQeFSGpY=; b=kROn9k5l1zUC+/coZ+ilfO8nu1kdoOGSxH810Wdrc33RT7rs/RAtJKhpdGYZnb3S5Z bqM0wD1I9XEjvQMKh5ck0tdkBSkGBiJswhgUF5h0aPkiwBrh7KF3J+rCmgD/JzH0NJuV wlN4vO/4n6wHPkKh33NntNTk+/DFQcOOU0hre+7eHPwnGnAImMsNCECi9ys125kqoeEG CnOr6jCdbx0WVNjXgy2Q6xC6L2K4WYE4ZFVBoM/K5k7ICUoN9mer5NHJUcsE0KYKsoOm B2tji+e2wQhit1J1rUDEFhMTLvZVxOeGOoQp6iWlsVtW9doSmojQUetTM5QekUxGPqA0 GnBw== MIME-Version: 1.0 X-Received: by 10.224.5.69 with SMTP id 5mr26268774qau.11.1391120501830; Thu, 30 Jan 2014 14:21:41 -0800 (PST) Sender: benlaurie@gmail.com Received: by 10.96.142.194 with HTTP; Thu, 30 Jan 2014 14:21:41 -0800 (PST) In-Reply-To: <888F991A-96C7-48C0-AAC6-0D432BD78A46@scsiguy.com> References: <84D23688-DDC6-421E-9D21-3DA646229038@scsiguy.com> <8680A21D-78D7-4B65-A502-17F0C3B70291@scsiguy.com> <888F991A-96C7-48C0-AAC6-0D432BD78A46@scsiguy.com> Date: Thu, 30 Jan 2014 22:21:41 +0000 X-Google-Sender-Auth: zZ40bAc8yeOO3K3WEEQYO746VhY Message-ID: Subject: Re: Dropped interrupts From: Ben Laurie To: "Justin T. Gibbs" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 22:21:43 -0000 On 26 January 2014 22:46, Justin T. Gibbs wrote: > On Jan 26, 2014, at 1:52 AM, Ben Laurie wrote: > >> On 25 January 2014 17:15, Justin T. Gibbs wrote: >>> On Jan 24, 2014, at 10:44 PM, Ben Laurie wrote: >>> >>>> Aha, finally got the error again... >>> >>> I don't know enough about your backup or Bacula to know if this is amou= nt that should be written, but we attempted a write in variable block mode = of 64512 bytes. >> >> I don;t think there's anything wrong with that. Not at the machine >> right now, but I think that's actually the default max block. No idea >> why. >> >>> The command, data transfer list, and controller state are all consisten= t with this. The command was successfully transferred to the tape drive, b= ut it never transitioned to data phase to allow us to begin the data transf= er. (In parallel SCSI, the target controls all state transitions). >>> >>> Since there are no parity errors or other indications of a transport er= ror, my hunch is that this is a tape drive issue. Are you running the late= st available firmware for it? >> >> No idea, its a very old LTO-2 drive. I'll see if I can find an update. >> >>> How many write cycles do you have on your media? >> >> I have seen this error on brand new media. I'd guess the most cycles >> any tape has had is around 10. >> >>> When was the last time you cleaned the drive? >> >> LTO drives are self-cleaning. So ... never. > > This is a popular misconception. LTO drives include brushes deployed dur= ing load or unload to remove large particle contamination off the head. Th= is increases the time interval between traditional cleanings, but doesn't m= ake them unnecessary. Certain LTO drives will tell you (e.g. light a LED) = when they require cleaning, but I don't know if this is one of them. There= have also been firmware bugs on some drives that prevent the cleaning indi= cator from working as expected. > > If the drive has over 500 hours on it, I would suggest a cleaning pass. Are you suggesting that a need for cleaning could cause this problem? > > -- > Justin From owner-freebsd-scsi@FreeBSD.ORG Fri Jan 31 00:33:57 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07532914; Fri, 31 Jan 2014 00:33:57 +0000 (UTC) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9425A164B; Fri, 31 Jan 2014 00:33:56 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id s0V0XhRn012850; Thu, 30 Jan 2014 17:33:43 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id s0V0XguJ012849; Thu, 30 Jan 2014 17:33:42 -0700 (MST) (envelope-from ken) Date: Thu, 30 Jan 2014 17:33:42 -0700 From: "Kenneth D. Merry" To: Garrett Wollman Subject: Re: Heap overflow in mps(4) (was: Re: stable/9 mps(4) rev 254938 == BOOM!) Message-ID: <20140131003342.GA11755@nargothrond.kdm.org> References: <21225.19508.683025.581620@khavrinen.csail.mit.edu> <201401292137.s0TLbD5G006716@hergotha.csail.mit.edu> <20140129221514.GA47535@nargothrond.kdm.org> <21225.38749.179621.454579@khavrinen.csail.mit.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline In-Reply-To: <21225.38749.179621.454579@khavrinen.csail.mit.edu> User-Agent: Mutt/1.4.2i Cc: freebsd-scsi@freebsd.org, scottl@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 00:33:57 -0000 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jan 29, 2014 at 19:05:49 -0500, Garrett Wollman wrote: > < said: > > > Are you booting off of the controller? If not, could you try building mps > > as a module and unloading it? Perhaps the memory would get freed when the > > module is unloaded and the redzone code would show where the problem is. > > I built a memory-stick image and tried this. No redzone messages, but > the driver leaks 18 allocations (142336 bytes). The attached patch should fix the leaked allocations. I'm CCing Steve and Kashyap at LSI so that they can verify that this is the right place to do the mapping shutdown. I don't know yet why that particular change is causing problems. Perhaps it just moved things around and exposed an existing problem. The fact that the redzone code doesn't expose any problems makes it more likely that it is a problem other than a heap overflow. Since it is consistent, is there any chance you could hook up remote gdb to the box and poke around when it crashes? Perhaps you'll see something interesting that will point to the problem. Ken -- Kenneth Merry ken@FreeBSD.ORG --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mps_memory_leak.20140130.txt" ==== //depot/vendor/FreeBSD/stable/9/sys/dev/mps/mps.c#8 - /usr/home/kenm/perforce5/vendor/FreeBSD/stable/9/sys/dev/mps/mps.c ==== *** /tmp/tmp.75208.67 Thu Jan 30 17:13:27 2014 --- /usr/home/kenm/perforce5/vendor/FreeBSD/stable/9/sys/dev/mps/mps.c Thu Jan 30 17:12:59 2014 *************** *** 1621,1626 **** --- 1621,1629 ---- /* Turn off the watchdog */ mps_lock(sc); sc->mps_flags |= MPS_FLAGS_SHUTDOWN; + + mps_mapping_exit(sc); + mps_unlock(sc); /* Lock must not be held for this */ callout_drain(&sc->periodic); --bg08WKrSYDhXBjb5-- From owner-freebsd-scsi@FreeBSD.ORG Fri Jan 31 00:44:47 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADCDEC14 for ; Fri, 31 Jan 2014 00:44:47 +0000 (UTC) Received: from aslan.scsiguy.com (mail.scsiguy.com [70.89.174.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6EF4A172C for ; Fri, 31 Jan 2014 00:44:46 +0000 (UTC) Received: from jt-mbp.home.scsiguy.org (jt-mbp.home.scsiguy.org [192.168.0.61]) (authenticated bits=0) by aslan.scsiguy.com (8.14.7/8.14.7) with ESMTP id s0V0ifc5008801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 Jan 2014 17:44:44 -0700 (MST) (envelope-from gibbs@scsiguy.com) Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Dropped interrupts From: "Justin T. Gibbs" In-Reply-To: Date: Thu, 30 Jan 2014 17:44:41 -0700 Message-Id: <80532F4C-9206-4268-936E-66F352087052@scsiguy.com> References: <84D23688-DDC6-421E-9D21-3DA646229038@scsiguy.com> <8680A21D-78D7-4B65-A502-17F0C3B70291@scsiguy.com> <888F991A-96C7-48C0-AAC6-0D432BD78A46@scsiguy.com> To: Ben Laurie X-Mailer: Apple Mail (2.1827) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 00:44:47 -0000 On Jan 30, 2014, at 3:21 PM, Ben Laurie wrote: > On 26 January 2014 22:46, Justin T. Gibbs wrote: >> On Jan 26, 2014, at 1:52 AM, Ben Laurie wrote: >>=20 >>> On 25 January 2014 17:15, Justin T. Gibbs wrote: >>>> On Jan 24, 2014, at 10:44 PM, Ben Laurie wrote: >>>>=20 >>>>> Aha, finally got the error again... >>>>=20 >>>> I don't know enough about your backup or Bacula to know if this is = amount that should be written, but we attempted a write in variable = block mode of 64512 bytes. >>>=20 >>> I don;t think there's anything wrong with that. Not at the machine >>> right now, but I think that's actually the default max block. No = idea >>> why. >>>=20 >>>> The command, data transfer list, and controller state are all = consistent with this. The command was successfully transferred to the = tape drive, but it never transitioned to data phase to allow us to begin = the data transfer. (In parallel SCSI, the target controls all state = transitions). >>>>=20 >>>> Since there are no parity errors or other indications of a = transport error, my hunch is that this is a tape drive issue. Are you = running the latest available firmware for it? >>>=20 >>> No idea, its a very old LTO-2 drive. I'll see if I can find an = update. >>>=20 >>>> How many write cycles do you have on your media? >>>=20 >>> I have seen this error on brand new media. I'd guess the most cycles >>> any tape has had is around 10. >>>=20 >>>> When was the last time you cleaned the drive? >>>=20 >>> LTO drives are self-cleaning. So ... never. >>=20 >> This is a popular misconception. LTO drives include brushes deployed = during load or unload to remove large particle contamination off the = head. This increases the time interval between traditional cleanings, = but doesn't make them unnecessary. Certain LTO drives will tell you = (e.g. light a LED) when they require cleaning, but I don't know if this = is one of them. There have also been firmware bugs on some drives that = prevent the cleaning indicator from working as expected. >>=20 >> If the drive has over 500 hours on it, I would suggest a cleaning = pass. >=20 > Are you suggesting that a need for cleaning could cause this problem? I can=92t say why the drive isn=92t responding. But if it hasn=92t been = cleaned since it was manufactured, you are probably getting less data = per tape than optimal, slower transfer speeds than optimal, or both. I don=92t know if the LTO-2 model listed on this page is the same as = what you have, but if it is, there were several firmware releases after = 3AYC: http://www-01.ibm.com/support/docview.wss?uid=3Dssg1S4000055 =97 Justin= From owner-freebsd-scsi@FreeBSD.ORG Fri Jan 31 17:37:09 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6743A910 for ; Fri, 31 Jan 2014 17:37:09 +0000 (UTC) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1E72B174A for ; Fri, 31 Jan 2014 17:37:09 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id i17so7467459qcy.39 for ; Fri, 31 Jan 2014 09:37:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6ga8e+FlaqN8FJ3eQCi3REuwF1IXRuI79diKciREmN8=; b=uNYElOoqIeWFqQBG6oVcmj63XpZJ4ELP/AQ0MSd5pZlFUIDMhP+8x2Sm229/uPZ7XP 2yTcTNYjz1UxkJgCkZiNlP0YoLhnRgZGl2dYcq6cOc6L6NsYKvEGsM+QOIIXcCLp9Wf1 fPZM+1Lb8ck/SxpT1PTbN66hOvnYo38tehwgDDg1KuKiNYX73gNzMunnkxK6wilPPiX1 OHU/rVkL2gsp1g3YcZhZ4kTtdkre7jsxPYlO0hgcLs2Hs4naXuRMGbMODeLICR1zkUAN Ikw4hgpMYX5RWk5k+54Qq8WfB0bHjdPn7fxUAjVR9s2vxVdiC7LbSZoUwm5Dc4cdzTe5 bjaw== MIME-Version: 1.0 X-Received: by 10.229.71.69 with SMTP id g5mr33734332qcj.6.1391189522698; Fri, 31 Jan 2014 09:32:02 -0800 (PST) Sender: benlaurie@gmail.com Received: by 10.96.142.194 with HTTP; Fri, 31 Jan 2014 09:32:02 -0800 (PST) In-Reply-To: <80532F4C-9206-4268-936E-66F352087052@scsiguy.com> References: <84D23688-DDC6-421E-9D21-3DA646229038@scsiguy.com> <8680A21D-78D7-4B65-A502-17F0C3B70291@scsiguy.com> <888F991A-96C7-48C0-AAC6-0D432BD78A46@scsiguy.com> <80532F4C-9206-4268-936E-66F352087052@scsiguy.com> Date: Fri, 31 Jan 2014 17:32:02 +0000 X-Google-Sender-Auth: eU9CJylmBuFlZVn0b_8MRVcWR1M Message-ID: Subject: Re: Dropped interrupts From: Ben Laurie To: "Justin T. Gibbs" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 17:37:09 -0000 On 31 January 2014 00:44, Justin T. Gibbs wrote: > On Jan 30, 2014, at 3:21 PM, Ben Laurie wrote: > > On 26 January 2014 22:46, Justin T. Gibbs wrote: > > On Jan 26, 2014, at 1:52 AM, Ben Laurie wrote: > > On 25 January 2014 17:15, Justin T. Gibbs wrote: > > On Jan 24, 2014, at 10:44 PM, Ben Laurie wrote: > > Aha, finally got the error again... > > > I don't know enough about your backup or Bacula to know if this is amount > that should be written, but we attempted a write in variable block mode of > 64512 bytes. > > > I don;t think there's anything wrong with that. Not at the machine > right now, but I think that's actually the default max block. No idea > why. > > The command, data transfer list, and controller state are all consistent > with this. The command was successfully transferred to the tape drive, but > it never transitioned to data phase to allow us to begin the data transfer. > (In parallel SCSI, the target controls all state transitions). > > Since there are no parity errors or other indications of a transport error, > my hunch is that this is a tape drive issue. Are you running the latest > available firmware for it? > > > No idea, its a very old LTO-2 drive. I'll see if I can find an update. > > How many write cycles do you have on your media? > > > I have seen this error on brand new media. I'd guess the most cycles > any tape has had is around 10. > > When was the last time you cleaned the drive? > > > LTO drives are self-cleaning. So ... never. > > > This is a popular misconception. LTO drives include brushes deployed during > load or unload to remove large particle contamination off the head. This > increases the time interval between traditional cleanings, but doesn't make > them unnecessary. Certain LTO drives will tell you (e.g. light a LED) when > they require cleaning, but I don't know if this is one of them. There have > also been firmware bugs on some drives that prevent the cleaning indicator > from working as expected. > > If the drive has over 500 hours on it, I would suggest a cleaning pass. Probably has. I don't have a cleaning tape, though. > Are you suggesting that a need for cleaning could cause this problem? > > > I can't say why the drive isn't responding. But if it hasn't been cleaned > since it was manufactured, you are probably getting less data per tape than > optimal, slower transfer speeds than optimal, or both. > > I don't know if the LTO-2 model listed on this page is the same as what you > have, but if it is, there were several firmware releases after 3AYC: > > http://www-01.ibm.com/support/docview.wss?uid=ssg1S4000055 The install instructions (http://www-01.ibm.com/support/docview.wss?uid=ssg1S7000704&aid=1) make no sense in the context of my drive, so I guess not. From owner-freebsd-scsi@FreeBSD.ORG Fri Jan 31 20:15:30 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E181DABD for ; Fri, 31 Jan 2014 20:15:30 +0000 (UTC) Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A37FB153F for ; Fri, 31 Jan 2014 20:15:28 +0000 (UTC) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTPS for ; Fri, 31 Jan 2014 21:15:18 +0100 (CET) Received: from [192.168.69.226] (c83-252-98-74.bredband.comhem.se [83.252.98.74]) (Authenticated sender: turbo@bayour.com) by smtp-08-01.atm.binero.net (Postfix) with ESMTPSA id 451893A13B for ; Fri, 31 Jan 2014 21:15:18 +0100 (CET) Subject: Support for aoc-sas2lp-mv8? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Turbo Fredriksson Resent-From: Turbo Fredriksson Date: Fri, 31 Jan 2014 15:01:51 +0100 Content-Transfer-Encoding: 7bit Resent-Date: Fri, 31 Jan 2014 21:13:37 +0100 Resent-To: freebsd-scsi@freebsd.org Message-Id: <2D179406-C7BC-4678-B88F-F47B19B917FB@bayour.com> To: freebsd-scsi@freebsd.org X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 20:15:30 -0000 Is there any plans on adding support for this (88SE9485) Marvell card? I can, in some way at least, help fund this if someone have the interest and time to do it... From owner-freebsd-scsi@FreeBSD.ORG Sat Feb 1 11:24:38 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB6CBF0E for ; Sat, 1 Feb 2014 11:24:38 +0000 (UTC) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9229415CF for ; Sat, 1 Feb 2014 11:24:38 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id n7so8587119qcx.2 for ; Sat, 01 Feb 2014 03:24:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=zEp2heX9CQavTVpD/1EqpWTLqaSeBBDZBnZiI81VyKU=; b=wyJNJNC/sQtRSCGmr/a+8ovlkPjiO4c8cyVlFU0hiHDIjPDKC55JxmCPGf2enmaxkt 8TXb1Sgus4cjfFfuKx87dos3K3CDcY4kymF0h7c0m1BR5pHmG4u5trDNVJsLvPsVxdVb 0PyUgTU9tV5yY7gb1S27z+XjIQai9Y3PPLt0c7051Y8mTJaJZPTf1FgrfEp1CNhGXimS 7EbjDu1JaA/0WSGmbWpIAxuaDjNDPSakGs4uOQDqGZxfaxFKsfbEWDufbV930gWFm10Y zr3kJM0bqaXsO1+zPi84yGnScSzfj9Vob5098lGoqwE1+Oc9WXo/uoiONdKnpdQ4X4R9 e0pg== MIME-Version: 1.0 X-Received: by 10.224.3.10 with SMTP id 10mr39811108qal.58.1391253877657; Sat, 01 Feb 2014 03:24:37 -0800 (PST) Sender: benlaurie@gmail.com Received: by 10.96.142.194 with HTTP; Sat, 1 Feb 2014 03:24:37 -0800 (PST) In-Reply-To: References: <84D23688-DDC6-421E-9D21-3DA646229038@scsiguy.com> <8680A21D-78D7-4B65-A502-17F0C3B70291@scsiguy.com> <888F991A-96C7-48C0-AAC6-0D432BD78A46@scsiguy.com> <80532F4C-9206-4268-936E-66F352087052@scsiguy.com> Date: Sat, 1 Feb 2014 11:24:37 +0000 X-Google-Sender-Auth: 9XgnGORQDLyE926hl85S0UhuGHI Message-ID: Subject: Re: Dropped interrupts From: Ben Laurie To: "Justin T. Gibbs" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 11:24:38 -0000 On 31 January 2014 17:32, Ben Laurie wrote: > On 31 January 2014 00:44, Justin T. Gibbs wrote: >> On Jan 30, 2014, at 3:21 PM, Ben Laurie wrote: >> >> On 26 January 2014 22:46, Justin T. Gibbs wrote: >> >> On Jan 26, 2014, at 1:52 AM, Ben Laurie wrote: >> >> On 25 January 2014 17:15, Justin T. Gibbs wrote: >> >> On Jan 24, 2014, at 10:44 PM, Ben Laurie wrote: >> >> Aha, finally got the error again... >> >> >> I don't know enough about your backup or Bacula to know if this is amount >> that should be written, but we attempted a write in variable block mode of >> 64512 bytes. >> >> >> I don;t think there's anything wrong with that. Not at the machine >> right now, but I think that's actually the default max block. No idea >> why. >> >> The command, data transfer list, and controller state are all consistent >> with this. The command was successfully transferred to the tape drive, but >> it never transitioned to data phase to allow us to begin the data transfer. >> (In parallel SCSI, the target controls all state transitions). >> >> Since there are no parity errors or other indications of a transport error, >> my hunch is that this is a tape drive issue. Are you running the latest >> available firmware for it? >> >> >> No idea, its a very old LTO-2 drive. I'll see if I can find an update. >> >> How many write cycles do you have on your media? >> >> >> I have seen this error on brand new media. I'd guess the most cycles >> any tape has had is around 10. >> >> When was the last time you cleaned the drive? >> >> >> LTO drives are self-cleaning. So ... never. >> >> >> This is a popular misconception. LTO drives include brushes deployed during >> load or unload to remove large particle contamination off the head. This >> increases the time interval between traditional cleanings, but doesn't make >> them unnecessary. Certain LTO drives will tell you (e.g. light a LED) when >> they require cleaning, but I don't know if this is one of them. There have >> also been firmware bugs on some drives that prevent the cleaning indicator >> from working as expected. >> >> If the drive has over 500 hours on it, I would suggest a cleaning pass. > > Probably has. I don't have a cleaning tape, though. > >> Are you suggesting that a need for cleaning could cause this problem? >> >> >> I can't say why the drive isn't responding. But if it hasn't been cleaned >> since it was manufactured, you are probably getting less data per tape than >> optimal, slower transfer speeds than optimal, or both. >> >> I don't know if the LTO-2 model listed on this page is the same as what you >> have, but if it is, there were several firmware releases after 3AYC: >> >> http://www-01.ibm.com/support/docview.wss?uid=ssg1S4000055 > > The install instructions > (http://www-01.ibm.com/support/docview.wss?uid=ssg1S7000704&aid=1) > make no sense in the context of my drive, so I guess not. There does seem to be a firmware upgrade, though. http://www.dell.com/support/drivers/us/en/19/DriverDetails/Product/powervault-lto2-110t?driverId=H29Y4&osCode=WNET&fileId=2731097569&languageCode=en&categoryId=TH#OldVersion. But ... dunno how to install it. The Linux tools don't work under FreeBSD, it seems.