Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

Nick Wolff-2
I just tested the snapshot from 20190725 and still am getting the root
mount rating for "boot on boot. I think something deeper broke between
r349133 and r349160 because even when I turn off wait for Root Mount on usb
root via a loader variable boot just get's stuck later on in the process.

This is all happening on an x11-dpi-nt board.

http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.0/FreeBSD-13.0-CURRENT-amd64-20190725-r350322-disc1.iso

On Mon, Jul 22, 2019 at 12:57 PM Nick Wolff <[hidden email]> wrote:

> Hans,
>
> I'm building r350003  at the moment which is after the acpi change was
> moved into an unloaded module.
>
>
>
> On Mon, Jul 22, 2019 at 12:13 PM Hans Petter Selasky <[hidden email]>
> wrote:
>
>> On 2019-07-22 17:23, Nick Wolff wrote:
>> > Sorry for email spam but I was wrong. Just gets stuck now during
>> reproping
>> > a pci device after init happens(this is actually a trueos build which is
>> > why you see openrc). That device it's getting stuck on is "Sky Lake-E
>> CBDMA
>> > Registers" which shouldn't have a driver attached.
>> >
>> https://drive.google.com/file/d/19NFI0Dcupu3ZcVxbcr2vYFZ-iDqiIzkx/view?usp=sharing
>> >
>> > Though it maybe something else getting stuck at this point and that just
>> > happens to be the last thing on the screen.
>> >
>>
>> There was a recent change to add an ACPI wrapper for the USB HUB driver,
>> but that was a bit premature and introduced some bugs. For now the ACPI
>> USB HUB wrapper is not enabled by default. Do you experience issues with
>> the latest -current ?
>>
>> --HPS
>>
>>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

Rodney W. Grimes-6
> The .iso files are for a dvd install. If you want to use a usb, download
> the .img files.
>
> FreeBSD-13.0-CURRENT-amd64-20190725-r350322-memstick.img
> <https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/FreeBSD-13.0-CURRENT-amd64-20190725-r350322-memstick.img>

The FreeBSD projects amd64 .iso images are hybrid now,
they should work both as a memstick image and as a burned .iso.

IFF this is failing it is a bug and should be addressed.

file FreeBSD-13.0-CURRENT-amd64-20181213-r342020-disc1.iso
FreeBSD-13.0-CURRENT-amd64-20181213-r342020-disc1.iso: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 1758779 sectors

file FreeBSD-12.0-CURRENT-amd64-20171206-r326622-disc1.iso
FreeBSD-12.0-CURRENT-amd64-20171206-r326622-disc1.iso: ISO 9660 CD-ROM filesystem data '12_0_CURRENT_AMD64_CD' (bootable)


> ( or get the .xz version and extract it on your machine - it's smaller)
>
> This "mount root" problem got me too, so don't feel alone.
>
> Clay
> clay@fbsd13:~ $ uname -a
> FreeBSD fbsd13 13.0-CURRENT FreeBSD 13.0-CURRENT r350322 GENERIC  amd64
>
>
> On Mon, Jul 29, 2019 at 4:03 PM Nick Wolff <[hidden email]> wrote:
>
> > I just tested the snapshot from 20190725 and still am getting the root
> > mount rating for "boot on boot. I think something deeper broke between
> > r349133 and r349160 because even when I turn off wait for Root Mount on usb
> > root via a loader variable boot just get's stuck later on in the process.
> >
> > This is all happening on an x11-dpi-nt board.
> >
> >
> > http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.0/FreeBSD-13.0-CURRENT-amd64-20190725-r350322-disc1.iso
> >
> > On Mon, Jul 22, 2019 at 12:57 PM Nick Wolff <[hidden email]>
> > wrote:
> >
> > > Hans,
> > >
> > > I'm building r350003  at the moment which is after the acpi change was
> > > moved into an unloaded module.
> > >
> > >
> > >
> > > On Mon, Jul 22, 2019 at 12:13 PM Hans Petter Selasky <[hidden email]>
> > > wrote:
> > >
> > >> On 2019-07-22 17:23, Nick Wolff wrote:
> > >> > Sorry for email spam but I was wrong. Just gets stuck now during
> > >> reproping
> > >> > a pci device after init happens(this is actually a trueos build which
> > is
> > >> > why you see openrc). That device it's getting stuck on is "Sky Lake-E
> > >> CBDMA
> > >> > Registers" which shouldn't have a driver attached.
> > >> >
> > >>
> > https://drive.google.com/file/d/19NFI0Dcupu3ZcVxbcr2vYFZ-iDqiIzkx/view?usp=sharing
> > >> >
> > >> > Though it maybe something else getting stuck at this point and that
> > just
> > >> > happens to be the last thing on the screen.
> > >> >
> > >>
> > >> There was a recent change to add an ACPI wrapper for the USB HUB driver,
> > >> but that was a bit premature and introduced some bugs. For now the ACPI
> > >> USB HUB wrapper is not enabled by default. Do you experience issues with
> > >> the latest -current ?
> > >>
> > >> --HPS
> > >>
> > >>
> > _______________________________________________
> > [hidden email] mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "[hidden email]"
> >
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[hidden email]"
>

--
Rod Grimes                                                 [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

Nick Wolff-2
Sorry boot is broken from harddrive or iso(as cdrom) for some users(at
least 3) since somewhere in the revisions listed above and that still
stands as of the Head snapshot of 072519. Sorry for lack of clarity. There
was a thread under Problem with USB after r349133 but I decided to rename
it to try to catch more people's eyes/get more reports in if people run
into the issue. Don't think or at least know for sure USB is the problem as
when you bypass the waiting for USB you get a different hang farther into
system booting.

I will try to bisect the build in that magic revision range once I figure
out on what system as it's my primary builder that's having this issue. Not
that I have a lack of hardware I guess just time to setup something else.




On Mon, Jul 29, 2019, 21:45 Clay Daniels Jr. <[hidden email]>
wrote:

> Rodney, you are right that the .iso "should work", and a lot of other
> projects, from Microsoft Windows 10 to Trident BSD only a furnish an iso,
> and no img file. FreeBSD is one of the few that give you both choices. The
> problem goes deeper than any one operating system. If you've ever used the
> Rufus tool to make a bootable usb, which is all Rufus does, you may have
> come across problems with "mount root". I found this article, answered by a
> Rufus developer very enlightening.
>
> https://superuser.com/questions/1170832/why-are-there-different-options-for-creating-bootable-usb-compared-to-a-cd
>
> I have a collection of usb thumbdrives here at my desk, and use them a
> lot, but I also bought me some blank dvd disks and use them too.
>
> But I think you are right, Nick Wolff's problem may be a a bug to be
> reported. All I know is I took the same file,
> FreeBSD-13.0-CURRENT-amd64-20190725-r350322-disc1.iso
> <https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/FreeBSD-13.0-CURRENT-amd64-20190725-r350322-disc1.iso>
> , burned it to a dvd, and I'm now writing this email from the FreeBSD
> 13.0-CURRENT r350322 partition of my computer.
>
> Clay
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

Scott Long-2
I’m 99% sure that the boot breakage is due to this commit:

Author: jkim
Date: Tue Jul  9 18:02:36 2019
New Revision: 349863
URL: https://svnweb.freebsd.org/changeset/base/349863

Log:
 MFV: r349861

 Import ACPICA 20190703.

I have two systems now that are affected, and both of them
are “fixed” by reverting this.  I don’t know the root cause yet,
see my email to the svn-src-all mailing list.

Scott

> On Jul 29, 2019, at 8:29 PM, Nick Wolff <[hidden email]> wrote:
>
> Sorry boot is broken from harddrive or iso(as cdrom) for some users(at
> least 3) since somewhere in the revisions listed above and that still
> stands as of the Head snapshot of 072519. Sorry for lack of clarity. There
> was a thread under Problem with USB after r349133 but I decided to rename
> it to try to catch more people's eyes/get more reports in if people run
> into the issue. Don't think or at least know for sure USB is the problem as
> when you bypass the waiting for USB you get a different hang farther into
> system booting.
>
> I will try to bisect the build in that magic revision range once I figure
> out on what system as it's my primary builder that's having this issue. Not
> that I have a lack of hardware I guess just time to setup something else.
>
>
>
>
> On Mon, Jul 29, 2019, 21:45 Clay Daniels Jr. <[hidden email]>
> wrote:
>
>> Rodney, you are right that the .iso "should work", and a lot of other
>> projects, from Microsoft Windows 10 to Trident BSD only a furnish an iso,
>> and no img file. FreeBSD is one of the few that give you both choices. The
>> problem goes deeper than any one operating system. If you've ever used the
>> Rufus tool to make a bootable usb, which is all Rufus does, you may have
>> come across problems with "mount root". I found this article, answered by a
>> Rufus developer very enlightening.
>>
>> https://superuser.com/questions/1170832/why-are-there-different-options-for-creating-bootable-usb-compared-to-a-cd
>>
>> I have a collection of usb thumbdrives here at my desk, and use them a
>> lot, but I also bought me some blank dvd disks and use them too.
>>
>> But I think you are right, Nick Wolff's problem may be a a bug to be
>> reported. All I know is I took the same file,
>> FreeBSD-13.0-CURRENT-amd64-20190725-r350322-disc1.iso
>> <https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/FreeBSD-13.0-CURRENT-amd64-20190725-r350322-disc1.iso>
>> , burned it to a dvd, and I'm now writing this email from the FreeBSD
>> 13.0-CURRENT r350322 partition of my computer.
>>
>> Clay
>>
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[hidden email]"

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

Hans Petter Selasky-6
Hi,

After tearing ACPI apart, there appears to be an issue like following:

1) AcpiUtAcquireMutex() doesn't support recursion, but also fails to
report an error when such a condition is occurring. Here is the
backtrace of the illegal mutex recursion.

 > AcpiUtAcquireMutex() at AcpiUtAcquireMutex+0x1fc/frame 0xffffffff834815d0
 > AcpiWalkNamespace() at AcpiWalkNamespace+0x8a/frame 0xffffffff83481640
 > AcpiNsInitializeObjects() at AcpiNsInitializeObjects+0x9b/frame
0xffffffff834816c0
 > AcpiExLoadTableOp() at AcpiExLoadTableOp+0x21c/frame 0xffffffff83481730
 > AcpiExOpcode_6A_0T_1R() at AcpiExOpcode_6A_0T_1R+0x22e/frame
0xffffffff83481790
 > AcpiDsExecEndOp() at AcpiDsExecEndOp+0x1dc/frame 0xffffffff83481830
 > AcpiPsParseLoop() at AcpiPsParseLoop+0x75a/frame 0xffffffff83481880
 > AcpiPsParseAml() at AcpiPsParseAml+0xfd/frame 0xffffffff834818d0
 > AcpiPsExecuteMethod() at AcpiPsExecuteMethod+0x27d/frame
0xffffffff83481940
 > AcpiNsEvaluate() at AcpiNsEvaluate+0x336/frame 0xffffffff834819b0
 > AcpiEvaluateObject() at AcpiEvaluateObject+0x223/frame 0xffffffff83481a10
 > AcpiEvaluateObjectTyped() at AcpiEvaluateObjectTyped+0xe0/frame
0xffffffff83481aa0
 > acpi_EvaluateOSC() at acpi_EvaluateOSC+0xef/frame 0xffffffff83481b90
 > acpi_cpu_attach() at acpi_cpu_attach+0x432/frame 0xffffffff83481cb0
 > DEVICE_ATTACH() at DEVICE_ATTACH+0x87/frame 0xffffffff83481cf0
 > device_attach() at device_attach+0xb9/frame 0xffffffff83481d80
 > device_probe_and_attach() at device_probe_and_attach+0x106/frame
0xffffffff83481dc0
 > bus_generic_attach() at bus_generic_attach+0x2c/frame 0xffffffff83481df0
 > acpi_probe_children() at acpi_probe_children+0x77/frame
0xffffffff83481e30
 > acpi_attach() at acpi_attach+0xbfe/frame 0xffffffff83482050
 > DEVICE_ATTACH() at DEVICE_ATTACH+0x87/frame 0xffffffff83482090
 > device_attach() at device_attach+0xb9/frame 0xffffffff83482120
 > device_probe_and_attach() at device_probe_and_attach+0x106/frame
0xffffffff83482160
 > bus_generic_attach() at bus_generic_attach+0x2c/frame 0xffffffff83482190
 > nexus_acpi_attach() at nexus_acpi_attach+0x59/frame 0xffffffff834821b0
 > DEVICE_ATTACH() at DEVICE_ATTACH+0x87/frame 0xffffffff834821f0
 > device_attach() at device_attach+0xb9/frame 0xffffffff83482280
 > device_probe_and_attach() at device_probe_and_attach+0x106/frame
0xffffffff834822c0
 > bus_generic_new_pass() at bus_generic_new_pass+0xb5/frame
0xffffffff83482300
 > BUS_NEW_PASS() at BUS_NEW_PASS+0x87/frame 0xffffffff83482340
 > bus_set_pass() at bus_set_pass+0x8f/frame 0xffffffff83482360
 > root_bus_configure() at root_bus_configure+0xe/frame 0xffffffff83482370
 > configure() at configure+0x11/frame 0xffffffff83482390
 > mi_startup() at mi_startup+0x2dc/frame 0xffffffff834823f0
 > btext() at btext+0x2c
 > ACPI Error: AE_ALREADY_ACQUIRED, During WalkNamespace
(20190703/nsinit-232)


The illegal mutex recursion ends up leaking a lock, which later on
causes a boot deadlock due to accesses to ACPI hanging forever.


2) This patch works around the issue.

 > diff --git a/sys/contrib/dev/acpica/components/utilities/utmutex.c
b/sys/contrib/dev/acpica/components/utilities/utmutex.c
 > index 4853bf5c3a6..33a67a731c6 100644
 > --- a/sys/contrib/dev/acpica/components/utilities/utmutex.c
 > +++ b/sys/contrib/dev/acpica/components/utilities/utmutex.c
 > @@ -378,6 +378,16 @@ AcpiUtAcquireMutex (
 >
 >      ThisThreadId = AcpiOsGetThreadId ();
 >
 > +    if (AcpiGbl_MutexInfo[MutexId].ThreadId == ThisThreadId)
 > +    {
 > +       ACPI_ERROR ((AE_INFO,
 > +           "Mutex [%s] already acquired by this thread [%u]",
 > +           AcpiUtGetMutexName (MutexId),
 > +           (UINT32) ThisThreadId));
 > +
 > +       return (AE_ALREADY_ACQUIRED);
 > +    }
 > +
 >  #ifdef ACPI_MUTEX_DEBUG
 >      {
 >          UINT32

--HPS

On 2019-08-01 15:58, Scott Long wrote:

> I’m 99% sure that the boot breakage is due to this commit:
>
> Author: jkim
> Date: Tue Jul  9 18:02:36 2019
> New Revision: 349863
> URL: https://svnweb.freebsd.org/changeset/base/349863
>
> Log:
>   MFV: r349861
>
>   Import ACPICA 20190703.
>
> I have two systems now that are affected, and both of them
> are “fixed” by reverting this.  I don’t know the root cause yet,
> see my email to the svn-src-all mailing list.
>



_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

Andriy Gapon
On 13/08/2019 16:31, Hans Petter Selasky wrote:
> 1) AcpiUtAcquireMutex() doesn't support recursion, but also fails to
> report an error when such a condition is occurring. Here is the
> backtrace of the illegal mutex recursion.

I have an old patch that replaces hand-rolled ACPI platform primitives
with thin wrappers around the standard kernel primitives.  It covers
locks and memory allocation.
I don't recall what objections there were when I originally proposed
that change.  I still think that it is a good idea.  The kernel code has
quite a bit more testing and tooling around it than the ACPI-only things.

--
Andriy Gapon
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"