From owner-freebsd-current@freebsd.org Fri Dec 6 23:41:08 2019 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3529A1BBA59 for ; Fri, 6 Dec 2019 23:41:08 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47V8H80NTsz45hP; Fri, 6 Dec 2019 23:41:07 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id xB6Nf5Pw001070 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 6 Dec 2019 15:41:05 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id xB6Nf5L2001069; Fri, 6 Dec 2019 15:41:05 -0800 (PST) (envelope-from sgk) Date: Fri, 6 Dec 2019 15:41:05 -0800 From: Steve Kargl To: Alexander Motin Cc: Warner Losh , FreeBSD Current Subject: Re: CAM breaks USB [was Re: USB causing boot to hang] Message-ID: <20191206234105.GA1027@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20191206202316.GA1053@troutmask.apl.washington.edu> <20191206223144.GA3224@troutmask.apl.washington.edu> <20191206225231.GA949@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47V8H80NTsz45hP X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 23:41:08 -0000 On Fri, Dec 06, 2019 at 06:15:32PM -0500, Alexander Motin wrote: > On 06.12.2019 17:52, Steve Kargl wrote: > > On Fri, Dec 06, 2019 at 03:33:09PM -0700, Warner Losh wrote: > >> On Fri, Dec 6, 2019 at 3:31 PM Steve Kargl > >> wrote: > >> > >>> On Fri, Dec 06, 2019 at 12:23:16PM -0800, Steve Kargl wrote: > >>>> I updates /usr/src to r355452, and updated by kernel and > >>>> world. Upon rebooting, verbose boot messages susgests > >>>> the system is hanging when USB starts to attach. With > >>>> the 3-week kernel verbose boot shows: > >>>> > >>>> ... > >>>> pcm4: Playback channel matrix is: 2.0 (unknown) > >>>> usbus0: 5.0Gbps Super Speed USB v3.0 > >>>> ... > >>>> > >>>> end with a prompt on the console. With today's kernel, > >>>> boot is hung after the last pcm4: message and no usbus0 > >>>> is displayed. > >>>> > >>>> The booting kernel/system is a > >>>> > >>>> % uname -a > >>>> FreeBSD 13.0-CURRENT #1 r354658: Wed Nov 13 11:23:32 PST 2019, amd64 > >>>> > >>>> Again, the failing kernel is r 355452 > >>>> > >>> > >>> The problem seems to be caused 355010. This is a commit to > >>> fix CAM, which seems to break USB. > >>> > >> > >> Yes. mav@ made this change... > >> > > > > src/UPDATING seems to be missing an entry about CAM breaking USB. > > And also that moon is made of cheese. :-\ > Not sure what you mean. You made a change, and the commit log even notes that there could be an issue. Yet, you want a user to waste half a day finding the root cause of the problem. > > The commit message for 355010 states: > > > > Devices appearing on USB bus later may still require setting > > kern.cam.boot_delay, but hopefully those are minority. > > > > There is no statement about "where" kern.cam.boot_delay should be set. > > There is no statement about "what" value(s) kern.cam.boot_delay should be. > > If you never needed it before, you still don't need it. Prior to 355010 the system just boots up. After 355010 the system hangs. Will kern.cam.boot_delay paper over whatever (latent?) bug you've exposed? > > For the record add kern.cam.boot_delay to /boot/loader.conf with the > > values 0, 1, and "1" did not allow the system to boot. > > boot_delay value is measured in milliseconds, so values of 0 and 1 mean > close to nothing. You may try to set it to some 10000, if you really > want to try to delay CAM devices attach, but I doubt. 0 and 1 were my guesses that boot_delay was an integer representation of a boolean value; 0 being disable the new code; 1 being enable new code. Looks like I guessed wrong given the documentation. > > The system > > will not boot with or without > > > > umass0 on uhub1 > > umass0: on usbus0 > > umass0: SCSI over Bulk-Only; quirks = 0x0100 > > umass0:9:0: Attached to scbus9 > > da0 at umass-sim0 bus 0 scbus9 target 0 lun 0 > > da0: Fixed Direct Access SPC-4 SCSI device > > da0: Serial Number NA7PEG27 > > da0: 400.000MB/s transfers > > da0: 3815447MB (7814037167 512 byte sectors) > > da0: quirks=0x2 > > > > plugged into the port. > > If system hangs even without any USB disk attached, then I don't see a > relation between CAM and USB here. My change could affect some timings > of the boot process, but without closer debugging it is hard to guess > something. To be sure whether USB is related I would try to disable all > USB controllers either in BIOS or with set of loader tunables like > hint.ehci.0.disabled=1 , hint.ohci.0.disabled=1 , > hint.xhci.0.disabled=1, ... Yep. Completely disabling USB allows the system to boot. I don't see how this would be unexpected as umass using cam. -- Steve