[Bug 224330] head -r326347 breaks USB on rpi2 and pine64 (and likely more)

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224330

            Bug ID: 224330
           Summary: head -r326347 breaks USB on rpi2 and pine64 (and
                    likely more)
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: markmi at dsl-only.net

[This may be related to bugzilla 224080 that is also for
-r326347 problems.]

See Emmanuel Vadot's pine64 USB-breakage report at:

https://lists.freebsd.org/pipermail/svn-src-head/2017-December/106954.html

He writes in part:

 This seems to break USB (EHCI and OHCI) on Pine64 (arm64)
 The board just hang when plugin usb device



In my case I saw this as a boot problem because I use
a USB SSD on a powered hub for the root file system.
(And I did not know about the above report yet.)

See my list messages for the rpi2 example:

https://lists.freebsd.org/pipermail/freebsd-current/2017-December/067771.html
https://lists.freebsd.org/pipermail/freebsd-current/2017-December/067799.html
https://lists.freebsd.org/pipermail/freebsd-current/2017-December/067807.html
https://lists.freebsd.org/pipermail/freebsd-current/2017-December/067811.html

My reports have some material from db> prompt
commands (but I'm no expert at what to pick
to show for this).

In my case I did a bisect sequence to find the
-r326346-and-before good / -r325347-and-later bad
boundary: I had jumped from -r326192 to -r326726
but had the problem.

Some db> material is from -r326726 before the
bisect and other material is from -r326347 .

The kernel thread (100001) involves:

. . .
uma_zcreate() at uma_zcreate+0x10c
         pc = 0xc052b024  lr = 0xc050cc90 (ffs_mount+0x80)
         sp = 0xd42a5858  fp = 0xd42a5980
         r4 = 0xd7844000  r5 = 0x00000000
         r6 = 0x00000003  r7 = 0xc09a99c0
         r8 = 0x00000000  r9 = 0xd429f000
        r10 = 0xd828c400
ffs_mount() at ffs_mount+0x80
         pc = 0xc050cc90  lr = 0xc032e1d4 (vfs_donmount+0xeec)
         sp = 0xd42a5988  fp = 0xd42a5b38
         r4 = 0xffffffff  r5 = 0xd74ec120
         r6 = 0xd429f000  r7 = 0x00000000
         r8 = 0x00000000  r9 = 0xc425acd0
        r10 = 0xd828c400
. . .

The uma thread involves:

. . .
uma_reclaim_locked() at uma_reclaim_locked+0x200
         pc = 0xc052d9f8  lr = 0xc052de70 (uma_reclaim_worker+0x4c)
         sp = 0xd87dadf0  fp = 0xd87dae20
         r4 = 0xc09a9c68  r5 = 0xc4242d80
         r6 = 0xc06df86e  r7 = 0x00000000
         r8 = 0x00000100  r9 = 0xc09b3d08
        r10 = 0xc09a9c7c
uma_reclaim_worker() at uma_reclaim_worker+0x4c
         pc = 0xc052de70  lr = 0xc0230f10 (fork_exit+0xa0)
         sp = 0xd87dae28  fp = 0xd87dae40
         r4 = 0xd7ad8740  r5 = 0xd70ce000
         r6 = 0xc052de24  r7 = 0x00000000
         r8 = 0xd87dae48  r9 = 0xd7ada3a0
        r10 = 0xc0824e8c
. . .

-- 
You are receiving this mail because:
You are the assignee for the bug.