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
___
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: Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

[Hans Petter Selasky]

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 0x834815d0
> AcpiWalkNamespace() at AcpiWalkNamespace+0x8a/frame 0x83481640
> AcpiNsInitializeObjects() at AcpiNsInitializeObjects+0x9b/frame 
0x834816c0

> AcpiExLoadTableOp() at AcpiExLoadTableOp+0x21c/frame 0x83481730
> AcpiExOpcode_6A_0T_1R() at AcpiExOpcode_6A_0T_1R+0x22e/frame 
0x83481790

> AcpiDsExecEndOp() at AcpiDsExecEndOp+0x1dc/frame 0x83481830
> AcpiPsParseLoop() at AcpiPsParseLoop+0x75a/frame 0x83481880
> AcpiPsParseAml() at AcpiPsParseAml+0xfd/frame 0x834818d0
> AcpiPsExecuteMethod() at AcpiPsExecuteMethod+0x27d/frame 
0x83481940

> AcpiNsEvaluate() at AcpiNsEvaluate+0x336/frame 0x834819b0
> AcpiEvaluateObject() at AcpiEvaluateObject+0x223/frame 0x83481a10
> AcpiEvaluateObjectTyped() at AcpiEvaluateObjectTyped+0xe0/frame 
0x83481aa0

> acpi_EvaluateOSC() at acpi_EvaluateOSC+0xef/frame 0x83481b90
> acpi_cpu_attach() at acpi_cpu_attach+0x432/frame 0x83481cb0
> DEVICE_ATTACH() at DEVICE_ATTACH+0x87/frame 0x83481cf0
> device_attach() at device_attach+0xb9/frame 0x83481d80
> device_probe_and_attach() at device_probe_and_attach+0x106/frame 
0x83481dc0

> bus_generic_attach() at bus_generic_attach+0x2c/frame 0x83481df0
> acpi_probe_children() at acpi_probe_children+0x77/frame 
0x83481e30

> acpi_attach() at acpi_attach+0xbfe/frame 0x83482050
> DEVICE_ATTACH() at DEVICE_ATTACH+0x87/frame 0x83482090
> device_attach() at device_attach+0xb9/frame 0x83482120
> device_probe_and_attach() at device_probe_and_attach+0x106/frame 
0x83482160

> bus_generic_attach() at bus_generic_attach+0x2c/frame 0x83482190
> nexus_acpi_attach() at nexus_acpi_attach+0x59/frame 0x834821b0
> DEVICE_ATTACH() at DEVICE_ATTACH+0x87/frame 0x834821f0
> device_attach() at device_attach+0xb9/frame 0x83482280
> device_probe_and_attach() at device_probe_and_attach+0x106/frame 
0x834822c0
> bus_generic_new_pass() at bus_generic_new_pass+0xb5/frame 
0x83482300

> BUS_NEW_PASS() at BUS_NEW_PASS+0x87/frame 0x83482340
> bus_set_pass() at bus_set_pass+0x8f/frame 0x83482360
> root_bus_configure() at root_bus_configure+0xe/frame 0x83482370
> configure() at configure+0x11/frame 0x83482390
> mi_startup() at mi_startup+0x2dc/frame 0x834823f0
> 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.





___
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: Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

[Scott Long]

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  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. 
> 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
>> 
>> , burned it to a dvd, and I'm now writing this email from the FreeBSD
>> 13.0-CURRENT r350322 partition of my computer.
>> 
>> Clay
>> 
> ___
> 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"

___
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: Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

[Nick Wolff]

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. 
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
> 
> , burned it to a dvd, and I'm now writing this email from the FreeBSD
> 13.0-CURRENT r350322 partition of my computer.
>
> Clay
>
___
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: Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

[Clay Daniels Jr.]

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

, burned it to a dvd, and I'm now writing this email from the FreeBSD
13.0-CURRENT r350322 partition of my computer.

Clay
___
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: Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

[Rodney W. Grimes]

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

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  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 
> > 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 
> > > 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
> > >>
> > >>
> > ___
> > 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"
> >
> ___
> 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"
> 

-- 
Rod Grimes rgri...@freebsd.org
___
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: Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

[Clay Daniels Jr.]

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


( 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  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 
> 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 
> > 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
> >>
> >>
> ___
> 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"
>
___
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"