Re: CAM breaks USB [was Re: USB causing boot to hang]

On 06.12.2019 18:41, Steve Kargl wrote:
> 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 <sgk_at_troutmask.apl.washington.edu>
>>>> wrote:
>>>>> The problem seems to be caused 355010.  This is a commit to
>>>>> fix CAM, which seems to break USB.
>>>>>
>>>> Yes. mav_at_ 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. 

I mean that if we are going to write there random fairy-tales, then I
prefer my moon.

If serious, then my change did not change semantics of any existing
tunables, only the way some of them are implemented, so there was
nothing to write in UPDATING.

> 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.

I am sorry that you wasted your time, but quick and ungrounded blames is
the last thing I want to read on Friday evening after the long day.

>>> 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?

My change affected the timing of system boot process, allowing system to
continue booting some further, not waiting for CAM to scan its buses and
disks.  If the problem is reproducible even without USB storage, then
CAM probably does not wait for it, so it is not the problem I first
thought about.

>> 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.

umass uses CAM, but you've told the problem happens even without umass,
that is why I told that I don't see any relation.  Does disabling of
_all_ USB fixes the problem?  Have you tried to narrow it down to
specific controller or device?

Is there anything special in your system?  Are you running GENERIC
kernel?  If not, then what do you have changed?

If your kernel includes VERBOSE_SYSINIT as GENERIC does, I would try to
set debug.verbose_sysinit=1 and see how far the boot process goes and at
which stage it may is hanging (if we guess that hang is related to the
stage and not asynchronous).

-- 
Alexander Motin