Re: Add support for ACPI Module Device ACPI0004?

2017-05-01 Thread Sepherosa Ziehau 
On Tue, May 2, 2017 at 12:25 AM, John Baldwin  wrote:
> On Sunday, April 30, 2017 09:02:30 AM Sepherosa Ziehau wrote:
>> On Sat, Apr 29, 2017 at 12:01 AM, John Baldwin  wrote:
>> > On Friday, April 28, 2017 05:38:32 PM Sepherosa Ziehau wrote:
>> >> On Thu, Apr 27, 2017 at 12:14 AM, John Baldwin  wrote:
>> >> > On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote:
>> >> >> On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin  wrote:
>> >> >> > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
>> >> >> >> > From: John Baldwin [mailto:j...@freebsd.org]
>> >> >> >> > Sent: Thursday, April 20, 2017 02:34
>> >> >> >> > > Can we add the support of "ACPI0004" with the below one-line 
>> >> >> >> > > change?
>> >> >> >> > >
>> >> >> >> > >  acpi_sysres_probe(device_t dev)
>> >> >> >> > >  {
>> >> >> >> > > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
>> >> >> >> > > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", 
>> >> >> >> > > "ACPI0004", NULL };
>> >> >> >> > >
>> >> >> >> > Hmm, so the role of C01 and C02 is to reserve system resources, 
>> >> >> >> > though we
>> >> >> >> > in turn allow any child of acpi0 to suballocate those ranges 
>> >> >> >> > (since historically
>> >> >> >> > c01 and c02 tend to allocate I/O ranges that are then used by 
>> >> >> >> > things like the
>> >> >> >> > EC, PS/2 keyboard controller, etc.).  From my reading of ACPI0004 
>> >> >> >> > in the ACPI
>> >> >> >> > 6.1 spec it's not quite clear that ACPI0004 is like that?  In 
>> >> >> >> > particular, it
>> >> >> >> > seems that 004 should only allow direct children to suballocate?  
>> >> >> >> > This
>> >> >> >> > change might work, but it will allow more devices to allocate the 
>> >> >> >> > ranges in
>> >> >> >> >  _CRS than otherwise.
>> >> >> >> >
>> >> >> >> > Do you have an acpidump from a guest system that contains an 
>> >> >> >> > ACPI0004
>> >> >> >> > node that you can share?
>> >> >> >> >
>> >> >> >> > John Baldwin
>> >> >> >>
>> >> >> >> Hi John,
>> >> >> >> Thanks for the help!
>> >> >> >>
>> >> >> >> Please see the attached file, which is got by
>> >> >> >> "acpidump -dt | gzip -c9 > acpidump.dt.gz"
>> >> >> >>
>> >> >> >> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
>> >> >> >> "VMBus" (VMBS).
>> >> >> >> It looks the _CRS of ACPI0004 is dynamically generated. Though we 
>> >> >> >> can't
>> >> >> >> see the length of the MMIO range in the dumped asl code, it does 
>> >> >> >> have
>> >> >> >> a 512MB MMIO range [0xFE000, 0xF].
>> >> >> >>
>> >> >> >> It looks FreeBSD can't detect ACPI0004 automatically.
>> >> >> >> With the above one-line change, I can first find the child device
>> >> >> >> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
>> >> >> >> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.
>> >> >> >>
>> >> >> >> If you think we shouldn't touch acpi_sysresource0 here, I guess
>> >> >> >> we can add a new small driver for ACPI0004, just like we added VMBus
>> >> >> >> driver as a child device of acpi0?
>> >> >> >
>> >> >> > Hmmm, so looking at this, the "right" thing is probably to have a 
>> >> >> > device
>> >> >> > driver for the ACPI0004 device that parses its _CRS and then allows 
>> >> >> > its
>> >> >> > child devices to sub-allocate resources from the ranges in _CRS.  
>> >> >> > However,
>> >> >> > this would mean make VMBus be a child of the ACPI0004 device.  
>> >> >> > Suppose
>> >> >> > we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0' 
>> >> >> > device
>> >> >> > would need to create a child device for all of its child devices.  
>> >> >> > Right
>> >> >> > now acpi0 also creates devices for them which is somewhat messy 
>> >> >> > (acpi0
>> >> >> > creates child devices anywhere in its namespace that have a valid 
>> >> >> > _HID).
>> >> >> > You can find those duplicates and remove them during acpi_module0's 
>> >> >> > attach
>> >> >> > routine before creating its own child device_t devices.  (We 
>> >> >> > associate
>> >> >> > a device_t with each Handle when creating device_t's for ACPI handles
>> >> >> > which is how you can find the old device that is a direct child of 
>> >> >> > acpi0
>> >> >> > so that it can be removed).
>> >> >>
>> >> >> The remove/reassociate vmbus part seems kinda "messy" to me.  I'd just
>> >> >> hook up a new acpi0004 driver, and let vmbus parse the _CRS like what
>> >> >> we did to the hyper-v's pcib0.
>> >> >
>> >> > The acpi_pci driver used to do the remove/reassociate part.  What acpi0
>> >> > should probably be doing is only creating device_t nodes for immediate
>> >> > children.  This would require an ACPI-aware isa0 for LPC devices below
>> >> > the ISA bus in the ACPI namespace.  We haven't done that in part because
>> >> > BIOS vendors are not always consistent in placing LPC devices under an
>> >> > ISA bus.  However, you otherwise have no good way to find

Re: regression suspend/resume on Lenovo T420

2017-05-01 Thread Adrian Chadd 
There were lots of commits that could break things. :-)


Can you compile up some intermediary versions between 315141 and
r317559 to find which commit range broke things? That'll make chasing
it down much quicker!

Thanks!


-a


On 29 April 2017 at 04:50, Manuel Stühn  wrote:
> Hi,
> I'd been sucessfully running CURRENT on my Lenovo T420 with functional
> suspend/resume since some time. But after updating to CURRENT r317032
> respectively r317559 suspend/resume does not work anymore. Putting it into
> suspend results only in a black screen, but no further action is possible
> (only pressing the powerbutton for some time to switch it off completely).
> The LEDs are not indicating any suspend mode.
> If i try to suspend it with X (intel-driver) stopped, the laptop does switch
> into suspend, but does not resume. It runs into some kind of resuming
> endless loop, where it tries to start the laptop again but at a certain
> point it restarts again. The screen stays dark all the time.
>
> I tried this with and without the following options but the same result.
> hw.acpi.reset_video=1
> dev.acpi_ibm.0.handlerevents='0x04'
>
> Booting a Bootenvironment with an older CURRENT(r315141), all is working.
> Was there any change between these commits concerning suspend/resume?
>
> BR
> Manuel
> ___
> 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: Add support for ACPI Module Device ACPI0004?

2017-05-01 Thread John Baldwin 
On Sunday, April 30, 2017 09:02:30 AM Sepherosa Ziehau wrote:
> On Sat, Apr 29, 2017 at 12:01 AM, John Baldwin  wrote:
> > On Friday, April 28, 2017 05:38:32 PM Sepherosa Ziehau wrote:
> >> On Thu, Apr 27, 2017 at 12:14 AM, John Baldwin  wrote:
> >> > On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote:
> >> >> On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin  wrote:
> >> >> > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
> >> >> >> > From: John Baldwin [mailto:j...@freebsd.org]
> >> >> >> > Sent: Thursday, April 20, 2017 02:34
> >> >> >> > > Can we add the support of "ACPI0004" with the below one-line 
> >> >> >> > > change?
> >> >> >> > >
> >> >> >> > >  acpi_sysres_probe(device_t dev)
> >> >> >> > >  {
> >> >> >> > > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
> >> >> >> > > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", 
> >> >> >> > > "ACPI0004", NULL };
> >> >> >> > >
> >> >> >> > Hmm, so the role of C01 and C02 is to reserve system resources, 
> >> >> >> > though we
> >> >> >> > in turn allow any child of acpi0 to suballocate those ranges 
> >> >> >> > (since historically
> >> >> >> > c01 and c02 tend to allocate I/O ranges that are then used by 
> >> >> >> > things like the
> >> >> >> > EC, PS/2 keyboard controller, etc.).  From my reading of ACPI0004 
> >> >> >> > in the ACPI
> >> >> >> > 6.1 spec it's not quite clear that ACPI0004 is like that?  In 
> >> >> >> > particular, it
> >> >> >> > seems that 004 should only allow direct children to suballocate?  
> >> >> >> > This
> >> >> >> > change might work, but it will allow more devices to allocate the 
> >> >> >> > ranges in
> >> >> >> >  _CRS than otherwise.
> >> >> >> >
> >> >> >> > Do you have an acpidump from a guest system that contains an 
> >> >> >> > ACPI0004
> >> >> >> > node that you can share?
> >> >> >> >
> >> >> >> > John Baldwin
> >> >> >>
> >> >> >> Hi John,
> >> >> >> Thanks for the help!
> >> >> >>
> >> >> >> Please see the attached file, which is got by
> >> >> >> "acpidump -dt | gzip -c9 > acpidump.dt.gz"
> >> >> >>
> >> >> >> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
> >> >> >> "VMBus" (VMBS).
> >> >> >> It looks the _CRS of ACPI0004 is dynamically generated. Though we 
> >> >> >> can't
> >> >> >> see the length of the MMIO range in the dumped asl code, it does have
> >> >> >> a 512MB MMIO range [0xFE000, 0xF].
> >> >> >>
> >> >> >> It looks FreeBSD can't detect ACPI0004 automatically.
> >> >> >> With the above one-line change, I can first find the child device
> >> >> >> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
> >> >> >> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.
> >> >> >>
> >> >> >> If you think we shouldn't touch acpi_sysresource0 here, I guess
> >> >> >> we can add a new small driver for ACPI0004, just like we added VMBus
> >> >> >> driver as a child device of acpi0?
> >> >> >
> >> >> > Hmmm, so looking at this, the "right" thing is probably to have a 
> >> >> > device
> >> >> > driver for the ACPI0004 device that parses its _CRS and then allows 
> >> >> > its
> >> >> > child devices to sub-allocate resources from the ranges in _CRS.  
> >> >> > However,
> >> >> > this would mean make VMBus be a child of the ACPI0004 device.  Suppose
> >> >> > we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0' 
> >> >> > device
> >> >> > would need to create a child device for all of its child devices.  
> >> >> > Right
> >> >> > now acpi0 also creates devices for them which is somewhat messy (acpi0
> >> >> > creates child devices anywhere in its namespace that have a valid 
> >> >> > _HID).
> >> >> > You can find those duplicates and remove them during acpi_module0's 
> >> >> > attach
> >> >> > routine before creating its own child device_t devices.  (We associate
> >> >> > a device_t with each Handle when creating device_t's for ACPI handles
> >> >> > which is how you can find the old device that is a direct child of 
> >> >> > acpi0
> >> >> > so that it can be removed).
> >> >>
> >> >> The remove/reassociate vmbus part seems kinda "messy" to me.  I'd just
> >> >> hook up a new acpi0004 driver, and let vmbus parse the _CRS like what
> >> >> we did to the hyper-v's pcib0.
> >> >
> >> > The acpi_pci driver used to do the remove/reassociate part.  What acpi0
> >> > should probably be doing is only creating device_t nodes for immediate
> >> > children.  This would require an ACPI-aware isa0 for LPC devices below
> >> > the ISA bus in the ACPI namespace.  We haven't done that in part because
> >> > BIOS vendors are not always consistent in placing LPC devices under an
> >> > ISA bus.  However, you otherwise have no good way to find your parent
> >> > ACPI0004 device.  You could perhaps find your ACPI handle, ask for its
> >> > parent handle, then ask for the device_t of that handle to find the
> >> > ACPI0004 device, but then you'd need to have

Re: Panic String: solaris assert: (lsize != psize) implies ((flags & ZIO_FLAG_RAW) != 0), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c, line: 631

2017-05-01 Thread Josh Paetzel 
> Andriy:
> 
> I am happy to report that the system no longer panics.  As requested I 
> removed
> the remaining logs (34G worth) and punished the file system as hard as I 
> could.
> 
> A scrub of the pool completed without error
> 
> Will the change be committed or do I need to open a PR?
> 
> Please let me know if I can supply additional information or if there 
> are any
> further tests you would like me to perform.
> 
> Thanks again for you prompt reply and apparent solution.
> 
> Regards,
> 
> Michael Jung
> ___
> 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"

Great news.  I committed the fix this morning.  Thanks for reporting the
problem and testing the fix.

-- 

Thanks,

Josh Paetzel
___
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: cross compiling freebsd-head is sigh, now broken - thanks libllvm

2017-05-01 Thread Dimitry Andric 
On 19 Mar 2017, at 08:00, Adrian Chadd  wrote:
> 
> ===> lib/clang (all)
> ===> lib/clang/libllvm (all)
> In file included from
> /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/math.h:309:0,
> from
> /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/cmath:305,
> from
> /usr/home/adrian/work/freebsd/head-embedded/src/lib/clang/include/llvm/Support/DataTypes.h:34,
> from
> /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/Hashing.h:48,
> from
> /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/ArrayRef.h:13,
> from
> /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/DenseMapInfo.h:17,
> from
> /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/DenseMap.h:17,
> from
> /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/IR/ValueMap.h:29,
> from
> /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/Transforms/Utils/ValueMapper.h:18,
> from
> /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/lib/Transforms/Utils/ValueMapper.cpp:15:
> /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:
> In substitution of 'template static
> std::__1::true_type
> std::__1::__is_constructible_helper::__test_nary(int) [with _Tp =
> {anonymous}::MDNodeMapper::Data; _Args = {}; 
> = ]':
> /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:2993:59:
>  required from 'struct
> std::__1::__is_default_constructible<{anonymous}::MDNodeMapper::Data,
> false>'
> /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:3015:8:
>  required from 'struct
> std::__1::__libcpp_is_constructible<{anonymous}::MDNodeMapper::Data>'
> /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:3043:29:
>  required from 'struct
> std::__1::is_constructible<{anonymous}::MDNodeMapper::Data>'
> /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:3229:29:
>  required from 'struct
> std::__1::is_default_constructible<{anonymous}::MDNodeMapper::Data>'
> /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/utility:352:15:
>  required from 'static constexpr bool std::__1::pair<_T1,
> _T2>::_CheckArgs::__enable_default() [with _U1 = const
> llvm::Metadata*; _U2 = {anonymous}::MDNodeMapper::Data; _T1 = const
> llvm::Metadata*; _T2 = {anonymous}::MDNodeMapper::Data]'
> /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home/adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/utility:403:71:
>  required by substitution of 'template std::__1::enable_if std::__1::pair {anonymous}::MDNodeMapper::Data>::_CheckArgs,
> std::__1::__check_tuple_constructor_fail>::type::
> __enable_default(), bool>::type  >
> constexpr std::__1::pair<_T1, _T2>::pair() [with bool _Dummy = true;
> typename std::__1::enable_if std::__1::conditional<_MaybeEnable, std::__1::pair llvm::Metadata*, {anonymous}::MDNodeMapper::Data>::_CheckArgs,
> std::__1::__check_tuple_constructor_fail>::type::
> __enable_default(), bool>::type  =
> ]'
> /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/DenseMap.h:39:8:
>  required from 'struct llvm::detail::DenseMapPair llvm::Metadata*, {anonymous}::MDNodeMapper::Data>'
> /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/Support/AlignOf.h:111:6:
>  required from 'class
> llvm::detail::AlignerImpl [32],
> llvm::SmallDenseMap {anonymous}::MDNodeMapper::Data, 32u>::LargeRep, char, char, char,
> char, char, char, char, char>'
> /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/Support/AlignOf.h:138:8:
>  required from 'struct
> llvm::AlignedCharArrayUnion [32],
> llvm::SmallDenseMap {anonymous}::MDNodeMapper::Data, 32u>::LargeRep, char, char, char,
> char, char, char, char, char>'
> /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/ADT/DenseMap.h:759:59:
>  required from 'class llvm::SmallDenseMap {anonymous}::MDNodeMapper::Data, 32u>'
>