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

[bob prohaska]

For what it's worth, there does seem to be something amiss with USB.

An RPI2 at r355446 is having difficulty finding its USB devices 
on a hands-off reboot. The problem wasn't apparent until this most
recent upgrade. Here's the console output:

DRAM: 944MB
Number of U-Boot devices: 1
U-Boot env: loaderdev='mmc 0'
Found U-Boot device: disk
  Checking unit=0 slice= partition=... good.
Booting from disk0s2a:
Loading /boot/defaults/loader.conf
/boot/kernel/kernel text=0x6b58cc data=0x93968+0x1edd98 
syms=[0x4+0x7b420+0x4+0xcacef]
/boot/entropy size=0x1000

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...   
Using DTB provided by U-Boot at address 0x100.
Kernel entry at 0x2200180...
Kernel args: (null)
---<>---
Copyright (c) 1992-2019 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 12.1-STABLE r355446 RPI2 arm
FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on LLVM 
8.0.1)
VT: init without driver.
CPU: ARM Cortex-A7 r0p5 (ECO: 0x)
CPU Features: 
  Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, VMSAv7,
  PXN, LPAE, Coherent Walk
Optional instructions: 
  SDIV/UDIV, UMULL, SMULL, SIMD(ext)
LoUU:2 LoC:3 LoUIS:2 
Cache level 1:
 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc
 32KB/32B 2-way instruction cache Read-Alloc
Cache level 2:
 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc
real memory  = 989851648 (943 MB)
avail memory = 955912192 (911 MB)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
random: unblocking device.
random: entropy device external interface
kbd0 at kbdmux0
ofwbus0: 
simplebus0:  mem 0x3f00-0x3fff on 
ofwbus0
lintc0:  mem 0x4000-0x40ff on simplebus0
intc0:  mem 0xb200-0xb3ff irq 4 on simplebus0
gpio0:  mem 0x20-0x2000af irq 5,6,7,8 on 
simplebus0
gpio0: read-only pins: 46,48-53.
gpio0: reserved pins: 48-53.
gpiobus0:  on gpio0
generic_timer0:  irq 0,1,2,3 on ofwbus0
Timecounter "ARM MPCore Timecounter" frequency 1920 Hz quality 1000
Event timer "ARM MPCore Eventtimer" frequency 1920 Hz quality 1000
bcmwd0:  mem 0x10001c-0x100027 on simplebus0
gpioc0:  on gpio0
iichb0:  mem 0x205000-0x20501f irq 9 on simplebus0
iichb1:  mem 0x804000-0x80401f irq 10 on simplebus0
spi0:  mem 0x204000-0x20401f irq 11 on simplebus0
spibus0:  on spi0
bcm_dma0:  mem 0x7000-0x7fff,0xe05000-0xe05fff irq 
12,13,14,15,16,17,18,19,20,21,22,23,24 on simplebus0
mbox0:  mem 0xb880-0xb8bf irq 25 on simplebus0
sdhci_bcm0:  mem 0x30-0x3000ff irq 26 on 
simplebus0
mmc0:  on sdhci_bcm0
uart0:  mem 0x201000-0x201fff irq 27 on simplebus0
uart0: console (115200,n,8,1)
vchiq0:  mem 0xb800-0xb84f irq 28 on simplebus0
vchiq: local ver 8 (min 3), remote ver 8.
pcm0:  on vchiq0
bcm283x_dwcotg0:  mem 
0x98-0x99 irq 29 on simplebus0
usbus0 on bcm283x_dwcotg0
cpulist0:  on ofwbus0
cpu0:  on cpulist0
bcm2835_cpufreq0:  on cpu0
cpu1:  on cpulist0
cpu2:  on cpulist0
cpu3:  on cpulist0
fb0:  on ofwbus0
fbd0 on fb0
VT: initialize with new VT driver "fb".
fb0: 656x416(656x416@0,0) 24bpp
fb0: fbswap: 1, pitch 1968, base 0x3daac000, screen_size 818688
gpioled0:  on ofwbus0
cryptosoft0: 
Timecounters tick every 1.000 msec
iicbus0:  on iichb0
iic0:  on iicbus0
iicbus1:  on iichb1
iic1:  on iicbus1
usbus0: 480Mbps High Speed USB v2.0
ugen0.1:  at usbus0
uhub0:  on usbus0
mmcsd0: 8GB  at mmc0 
41.6MHz/4bit/65535-block
bcm2835_cpufreq0: ARM 600MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF
Release APs
Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
Warning: no time-of-day clock registered, system time will not be set accurately
uhub0: 1 port with 1 removable, self powered
Setting hostuuid: 95acec23-6e2c-11e7-8cb9-b827eb1a5a4b.
Setting hostid: 0x6aebd8b6.
swapon: /dev/da0b: No such file or directory
Starting file system checks:
/dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/ufs/rootfs: clugen0.2:  at usbus0
euhub1 on uhub0
uhub1:  on 
usbus0
uhub1: MTT enabled
free (5579 frags, 12994 blocks, 2.3% fragmentation)
Can't stat /dev/da0d: No such file or directory
Can't stat /dev/da0e: No such file or directory
Can't stat /dev/da0d: No such file or directory
Can't stat /dev/da0e: No such file or directory
Can't stat /dev/da0a: No such file or directory
Can't stat /dev/da0a: No such file or directory
THE FOLLOWING FILE SYSTEMS HAD AN UNEXPECTED INCONSISTENCY:
ufs: /dev/da0d (/tmp), ufs: /dev/da0e (/usr), ufs: /dev/da0a (/var)
Warning! Some of the devices might not be available; retrying
Waiting 30s for the root mount holders: usbus0 CAMuhub1: 5 ports with 4 
removable, self powered
.ugen0.3:  at usbus0
smsc0 on uhub1
smsc0:  on usbus0
smsc0: chip 0xec00, rev. 0002
miibus0:  on smsc0
ukphy0:  PHY 1 on miibus0
ukphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ue0:  on smsc0

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

[Alexander Motin]

On 06.12.2019 21:08, Steve Kargl wrote:
> On Fri, Dec 06, 2019 at 07:09:55PM -0500, Alexander Motin wrote:
>> 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 
>> 
>> wrote:
>>> 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. 
>>
>> 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.
> 
> The system boots at 355009.
> The system hangs at 355010.
> 
> How about adding:  After revision 355010, the cam subsystem may cause
> the usb subsystem to hang during boot.  It is recommended to disable usb.
> 
> You even hint at problems in your original commit message.

All I told in the commit message, is that my change may not fix all
existing USB boot problems.  That is it.  Nothing more.  I would not
commit any change with known problems.  And I am still not convinced
that it is a problem of my change, not some other pre-existing problem
triggered by it.

-- 
Alexander Motin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Steve Kargl]

On Sat, Dec 07, 2019 at 01:16:13AM +0100, Hans Petter Selasky wrote:
> 
> There is an option you can compile into the kernel which will allow the 
> keyboard to enter the debugger.
> 
> options   ALT_BREAK_TO_DEBUGGER
> 
> Sounds to me like either a leaked refcount or that one thread is 
> spinning blocking execution of other threads.
> 

I tried setting the sysctls

hw.usb.umass.debug: 1
hw.usb.xhci.debug: 1
hw.usb.uhci.debug: 1
hw.usb.ohci.debug: 1
hw.usb.ehci.debug: 1

but when I rebooted I forgot to request a verbose boot.
There was no apparent debugging output to the console.
I try again on Monday to get additional information.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Steve Kargl]

On Fri, Dec 06, 2019 at 07:09:55PM -0500, Alexander Motin wrote:
> 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 
>  
>  wrote:
> > 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. 
> 
> 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.

The system boots at 355009.
The system hangs at 355010.

How about adding:  After revision 355010, the cam subsystem may cause
the usb subsystem to hang during boot.  It is recommended to disable usb.

You even hint at problems in your original commit message.

The system is at work and unattended until Monday.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Warner Losh]

On Fri, Dec 6, 2019 at 4:41 PM 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 <
> s...@troutmask.apl.washington.edu>
> > >> 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 1, 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.
>

There is a long, tangled history of multiple mechanisms being used to
control releasing mountroot() to do its thing. CAM  historically used one
method, while USB used another. I've not closely reviewed this change to
see what the issue might be, but if the system booted before, but doesn't
now, then there's been a de-facto bug introduce or exposed by this change.
Maybe it would be better to back out 355010 and have it reviewed and tested
more carefully. It's been tricky in the past to get right and since there's
issues that have come up, it might be best to take a more conservative
approach. If we can't get a quick resolution, I'd recommend that we go this
route...

Looking at the change, I see that it is a bit weird...  It ditches the 'do
all the config intr hook stuff' which completes before we look at the root
holds for using the root holds. In theory, this should be fine... however,
USB does root holds for its uhub exploration which then finds umass, which
needs its own enumeration  before it's usable as root. I need to see what
interlocks are there, but it does look a little like there might be a
chan

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

[Hans Petter Selasky]

On 2019-12-07 01:09, Alexander Motin wrote:

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 
wrote:

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.


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



Hi,

There is an option you can compile into the kernel which will allow the 
keyboard to enter the debugger.


options ALT_BREAK_TO_DEBUGGER

Sounds to me like either a leaked refcount or that one thread is 
spinning blocking execution of other threads.


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Alexander Motin]

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

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
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Steve Kargl]

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 1, 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
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Alexander Motin]

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

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

> 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 1, if you really
want to try to delay CAM devices attach, but I doubt.

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

-- 
Alexander Motin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Steve Kargl]

On Fri, Dec 06, 2019 at 02:52:31PM -0800, Steve Kargl wrote:
> 
> 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.
> 
> 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.  The system
> will not boot with or without
> 

Do I need to rebuild my kernel with the undocumented CAM_BOOT_DELAY?

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Steve Kargl]

On Fri, Dec 06, 2019 at 05:44:55PM -0500, Alexander Motin wrote:
> 
> Yes, I made the change, and it was supposed to improve USB
> inter-operation, but after reading this email I still have no clue what
> could be wrong, so ideas welcome.

Sorry about the initial vagueness.  It took a couple of hours
to bisect the problem.

> Steve, do you have some devices on that USB, especially umass(4)?  Have
> you tried to remove them?

On a good boot, this is what is reported by dmesg.  There is
a logitech USB mouse receiver and a Seagate USB hard drive.
It does not matter if the hard drive is plugged in or not.

% dmesg | grep -E ^u
usbus0 on xhci0
usbus1 on ohci0
usbus2: EHCI version 1.0
usbus2 on ehci0
usbus3 on ohci1
usbus4: EHCI version 1.0
usbus4 on ehci1
usbus5 on ohci2
usbus6 on ohci3
usbus7: EHCI version 1.0
usbus7 on ehci2
usbus0: 5.0Gbps Super Speed USB v3.0
usbus1: 12Mbps Full Speed USB v1.0
usbus2: 480Mbps High Speed USB v2.0
usbus3: 12Mbps Full Speed USB v1.0
usbus4: 480Mbps High Speed USB v2.0
usbus5: 12Mbps Full Speed USB v1.0
usbus6: 12Mbps Full Speed USB v1.0
usbus7: 480Mbps High Speed USB v2.0
ugen7.1:  at usbus7
uhub0 on usbus7
uhub0:  on usbus7
ugen6.1:  at usbus6
uhub1 on usbus6
uhub1:  on usbus6
ugen5.1:  at usbus5
uhub2 on usbus5
uhub2:  on usbus5
ugen4.1:  at usbus4
uhub3 on usbus4
uhub3:  on usbus4
ugen3.1:  at usbus3
uhub4 on usbus3
uhub4:  on usbus3
ugen2.1:  at usbus2
uhub5 on usbus2
uhub5:  on usbus2
ugen1.1:  at usbus1
uhub6 on usbus1
uhub6:  on usbus1
ugen0.1: <0x1106 XHCI root HUB> at usbus0
uhub7 on usbus0
uhub7: <0x1106 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
uhub2: 2 ports with 2 removable, self powered
uhub1: 4 ports with 4 removable, self powered
uhub4: 5 ports with 5 removable, self powered
uhub6: 5 ports with 5 removable, self powered
uhub7: 5 ports with 4 removable, self powered
ugen0.2:  at usbus0
uhub8 on uhub7
uhub8:  on usbus0
uhub8: 4 ports with 4 removable, self powered
uhub0: 4 ports with 4 removable, self powered
uhub3: 5 ports with 5 removable, self powered
uhub5: 5 ports with 5 removable, self powered
ugen0.3:  at usbus0
umass0 on uhub7
umass0:  on usbus0
umass0:  SCSI over Bulk-Only; quirks = 0x0100
umass0:9:0: Attached to scbus9
ugen3.2:  at usbus3
ums0 on uhub4
ums0:  on usbus3
ums0: 8 buttons and [XYZT] coordinates ID=0
uhid0 on uhub4
uhid0:  on usbus3

% dmesg | grep da0
Trying to mount root from ufs:/dev/ada0p2 [rw]...
da0 at umass-sim0 bus 0 scbus9 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number NA7PEGM0
da0: 400.000MB/s transfers
da0: 3815447MB (7814037167 512 byte sectors)
da0: quirks=0x2

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Steve Kargl]

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.

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.

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

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Alexander Motin]

On 06.12.2019 17:33, 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:  at nid 30 on hdaa1
> > pcm4: Playback:
> > pcm4:      Stream cap: 0x0005 AC3 PCM
> > pcm4:         PCM cap: 0x000e05f0 16 20 24 bits, 32 44 48 88 96
> 192 KHz
> > pcm4:             DAC: 6
> > pcm4:
> > pcm4:     nid=30 [pin: SPDIF-out (Grey Jack)]
> > pcm4:       + <- nid=6 [audio output] [src: pcm]
> > pcm4:
> > pcm4: Mixer "vol" -> "none": child=0x0010
> > pcm4: Mixer "pcm": parent="vol"
> > pcm4: Soft PCM mixer ENABLED
> > pcm4: Playback channel set is: Front Left, Front Right,
> > pcm4: Playback channel matrix is: 2.0 (unknown)
> > usbus0: 5.0Gbps Super Speed USB v3.0
> > usbus1: 12Mbps Full Speed USB v1.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...

Yes, I made the change, and it was supposed to improve USB
inter-operation, but after reading this email I still have no clue what
could be wrong, so ideas welcome.

Steve, do you have some devices on that USB, especially umass(4)?  Have
you tried to remove them?

-- 
Alexander Motin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Warner Losh]

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:  at nid 30 on hdaa1
> > pcm4: Playback:
> > pcm4:  Stream cap: 0x0005 AC3 PCM
> > pcm4: PCM cap: 0x000e05f0 16 20 24 bits, 32 44 48 88 96 192 KHz
> > pcm4: DAC: 6
> > pcm4:
> > pcm4: nid=30 [pin: SPDIF-out (Grey Jack)]
> > pcm4:   + <- nid=6 [audio output] [src: pcm]
> > pcm4:
> > pcm4: Mixer "vol" -> "none": child=0x0010
> > pcm4: Mixer "pcm": parent="vol"
> > pcm4: Soft PCM mixer ENABLED
> > pcm4: Playback channel set is: Front Left, Front Right,
> > pcm4: Playback channel matrix is: 2.0 (unknown)
> > usbus0: 5.0Gbps Super Speed USB v3.0
> > usbus1: 12Mbps Full Speed USB v1.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...

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Steve Kargl]

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:  at nid 30 on hdaa1
> pcm4: Playback:
> pcm4:  Stream cap: 0x0005 AC3 PCM
> pcm4: PCM cap: 0x000e05f0 16 20 24 bits, 32 44 48 88 96 192 KHz
> pcm4: DAC: 6
> pcm4: 
> pcm4: nid=30 [pin: SPDIF-out (Grey Jack)]
> pcm4:   + <- nid=6 [audio output] [src: pcm]
> pcm4: 
> pcm4: Mixer "vol" -> "none": child=0x0010
> pcm4: Mixer "pcm": parent="vol"
> pcm4: Soft PCM mixer ENABLED
> pcm4: Playback channel set is: Front Left, Front Right, 
> pcm4: Playback channel matrix is: 2.0 (unknown)
> usbus0: 5.0Gbps Super Speed USB v3.0
> usbus1: 12Mbps Full Speed USB v1.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.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: USB causing boot to hang

[Steve Kargl]

On Fri, Dec 06, 2019 at 09:32:01PM +, Bjoern A. Zeeb wrote:
> On 6 Dec 2019, at 20:23, 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:  at nid 30 on hdaa1
> > pcm4: Playback:
> > pcm4:  Stream cap: 0x0005 AC3 PCM
> > pcm4: PCM cap: 0x000e05f0 16 20 24 bits, 32 44 48 88 96 192 
> > KHz
> > pcm4: DAC: 6
> > pcm4:
> > pcm4: nid=30 [pin: SPDIF-out (Grey Jack)]
> > pcm4:   + <- nid=6 [audio output] [src: pcm]
> > pcm4:
> > pcm4: Mixer "vol" -> "none": child=0x0010
> > pcm4: Mixer "pcm": parent="vol"
> > pcm4: Soft PCM mixer ENABLED
> > pcm4: Playback channel set is: Front Left, Front Right,
> > pcm4: Playback channel matrix is: 2.0 (unknown)
> > usbus0: 5.0Gbps Super Speed USB v3.0
> > usbus1: 12Mbps Full Speed USB v1.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
> 
> I think I have seen this on around r355101 already in case it helps 
> narrowing things down.  I didn’t need USB and a few other things so I 
> removed them from the kernel config, which helped.

Yes, it's in that neighborhood.  I'm in the middle of a binary search
for the commit.  Fortunately, there is only about 1000 commits between
my last good kernel and the failing one.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: USB causing boot to hang

[Bjoern A. Zeeb]

On 6 Dec 2019, at 20:23, 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:  at nid 30 on hdaa1
pcm4: Playback:
pcm4:  Stream cap: 0x0005 AC3 PCM
pcm4: PCM cap: 0x000e05f0 16 20 24 bits, 32 44 48 88 96 192 
KHz

pcm4: DAC: 6
pcm4:
pcm4: nid=30 [pin: SPDIF-out (Grey Jack)]
pcm4:   + <- nid=6 [audio output] [src: pcm]
pcm4:
pcm4: Mixer "vol" -> "none": child=0x0010
pcm4: Mixer "pcm": parent="vol"
pcm4: Soft PCM mixer ENABLED
pcm4: Playback channel set is: Front Left, Front Right,
pcm4: Playback channel matrix is: 2.0 (unknown)
usbus0: 5.0Gbps Super Speed USB v3.0
usbus1: 12Mbps Full Speed USB v1.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


I think I have seen this on around r355101 already in case it helps 
narrowing things down.  I didn’t need USB and a few other things so I 
removed them from the kernel config, which helped.



/bz

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

USB causing boot to hang

[Steve Kargl]

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:  at nid 30 on hdaa1
pcm4: Playback:
pcm4:  Stream cap: 0x0005 AC3 PCM
pcm4: PCM cap: 0x000e05f0 16 20 24 bits, 32 44 48 88 96 192 KHz
pcm4: DAC: 6
pcm4: 
pcm4: nid=30 [pin: SPDIF-out (Grey Jack)]
pcm4:   + <- nid=6 [audio output] [src: pcm]
pcm4: 
pcm4: Mixer "vol" -> "none": child=0x0010
pcm4: Mixer "pcm": parent="vol"
pcm4: Soft PCM mixer ENABLED
pcm4: Playback channel set is: Front Left, Front Right, 
pcm4: Playback channel matrix is: 2.0 (unknown)
usbus0: 5.0Gbps Super Speed USB v3.0
usbus1: 12Mbps Full Speed USB v1.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


-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: kernel module code coverage

[Eric Joyner]

I didn't realize it was going to get updated so soon, but the versions on
that page were at "8.16.5" for the Windows and Linux versions when I sent
my email a couple days ago.

It also appears the versions for the OSs aren't all updated at the same
time (.6 seems to only includes Windows/macOS fixes), so it's still
possible we'll see 8.16.6 or 8.16.7 for FreeBSD later, absent any official
messaging.

On Fri, Dec 6, 2019 at 11:08 AM Jamie Landeg-Jones 
wrote:

> Eric Joyner  wrote:
>
> > I'm reviving an ancient thread, but is Bullseye truly dropping FreeBSD
> > support? Do you have a link to something that shows that?
> >
> > I still see a FreeBSD tarball in their download archive page for the
> newest
> > version of their tool, which seems to be 8.16.5.
>
> It appears that the "archive" is for older releases. The latest is 8.16.6
> and
> isn't listed for FreeBSD:
>
> https://www.bullseye.com/cgi-bin/download
>
> Cheers, Jamie
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: kernel module code coverage

[Jamie Landeg-Jones]

Eric Joyner  wrote:

> I'm reviving an ancient thread, but is Bullseye truly dropping FreeBSD
> support? Do you have a link to something that shows that?
>
> I still see a FreeBSD tarball in their download archive page for the newest
> version of their tool, which seems to be 8.16.5.

It appears that the "archive" is for older releases. The latest is 8.16.6 and
isn't listed for FreeBSD:

https://www.bullseye.com/cgi-bin/download

Cheers, Jamie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"