No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Daniel Eischen]

Greetings,

I'm trying to track down a couple of things.  amdtemp doesn't
report any temperature sensors, and acpi seems to have some
errors.  Not sure if they are related.

These are the ACPI-related warnings and errors during boot.

   Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has valid 
Length but zero Address: 0x/0x1 (20181031/tbfadt-796)

   acpi0:  on motherboard
   Firmware Error (ACPI): Failure creating [\134_SB.SMIC], AE_ALREADY_EXISTS 
(20181031/dswload2-477)
   ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog 
(20181031/psobject-372)
   Firmware Error (ACPI): Failure creating [\134_SB.SMIB], AE_ALREADY_EXISTS 
(20181031/dsfield-803)

The amdtemp module loads fine (including the dependent amdsmn), but
doesn't report any temperature related sysctls.

   $ sysctl -a | grep temp
   cd0: Attempt to query device size failed: NOT READY, Medium not present - 
tray closed
   cd0: Attempt to query device size failed: NOT READY, Medium not present- 
tray closed
   net.inet6.ip6.use_tempaddr: 0
   net.inet6.ip6.temppltime: 86400
   net.inet6.ip6.tempvltime: 604800
   net.inet6.ip6.prefer_tempaddr: 0
   hw.usb.template: -1
   kstat.zfs.misc.arcstats.arc_tempreserve: 0
   kstat.zfs.misc.zcompstats.attempts: 135280

Here's the relevent CPU line from dmesg.

   CPU: AMD Ryzen 5 2400G with Radeon Vega Graphics (3593.34-MHz K8-class 
CPU)
 Origin="AuthenticAMD"  Id=0x810f10  Family=0x17  Model=0x11  Stepping=0
 
Features=0x178bfbff
 
Features2=0x7ed8320b
 AMD Features=0x2e500800
 AMD 
Features2=0x35c233ff
 Structured Extended 
Features=0x209c01a9
 XSAVE Features=0xf
 AMD Extended Feature Extensions ID EBX=0x1007
 SVM: (disabled in BIOS) NP,NRIP,VClean,AFlush,DAssist,NAsids=32768
 TSC: P-state invariant, performance statistics

The full dmesg, /usr/sbin/acpidump -dt, and apcica-tools acpudumps
(with and without -s) are here:

   https://people.freebsd.org/~deischen/2400g/dmesg.txt
   https://people.freebsd.org/~deischen/2400g/acpidump.txt
   https://people.freebsd.org/~deischen/2400g/acpica.acpidump.txt

Thanks

--
DE
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Rozhuk Ivan]

On Tue, 13 Nov 2018 12:59:59 -0500 (EST)
Daniel Eischen  wrote:

> I'm trying to track down a couple of things.  amdtemp doesn't
> report any temperature sensors, and acpi seems to have some
> errors.  Not sure if they are related.

It s a bit legacy )
Try mine: http://www.netlab.linkpc.net/download/tmp/amdtemp.c
does not use amdsmn.

On newer BIOS it swap CurTmpTjSel and CurTmp, and CurTmp show >90C.
I dont know why, @cem may know.

dev.amdtemp.0.htc.PslApicLoEn: 1
dev.amdtemp.0.htc.PslApicHiEn: 1
dev.amdtemp.0.htc.HtcActSts: 1
dev.amdtemp.0.htc.HtcAct: 1
dev.amdtemp.0.htc.HtcPstateLimit: 7
dev.amdtemp.0.htc.HtcSlewSel: 1
dev.amdtemp.0.htc.HtcLock: 1
dev.amdtemp.0.htc.HtcEn: 1
dev.amdtemp.0.htc.HtcHystLmt: 7.6C
dev.amdtemp.0.htc.HtcTmpLmt: 115.6C
dev.amdtemp.0.tts.core1.sensor1_offset: 0
dev.amdtemp.0.tts.core1.sensor0_offset: 0
dev.amdtemp.0.tts.core1.sensor1: -0.9C
dev.amdtemp.0.tts.core1.sensor0: -0.9C
dev.amdtemp.0.tts.core0.sensor1_offset: 0
dev.amdtemp.0.tts.core0.sensor0_offset: 0
dev.amdtemp.0.tts.core0.sensor1: -0.9C
dev.amdtemp.0.tts.core0.sensor0: -0.9C
dev.amdtemp.0.tts.thermtrip: 0
dev.amdtemp.0.tts.sense: 1
dev.amdtemp.0.tts.enable: 0
dev.amdtemp.0.tts.DiodeOffset: 13
dev.amdtemp.0.tts.TjOffset: 0
dev.amdtemp.0.rtc.sensor_offset: 0
dev.amdtemp.0.rtc.PerStepTimeUp: 15
dev.amdtemp.0.rtc.PerStepTimeDn: 15
dev.amdtemp.0.rtc.TmpMaxDiffUp: 3
dev.amdtemp.0.rtc.TmpSlewDnEn: 1
dev.amdtemp.0.rtc.CurTmpTjSel: 1.6C
dev.amdtemp.0.rtc.CurTmp: 50.6C
dev.amdtemp.0.%parent: hostb10
dev.amdtemp.0.%pnpinfo: 
dev.amdtemp.0.%location: 
dev.amdtemp.0.%driver: amdtemp
dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors
dev.amdtemp.%parent: 
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Greg V]

On Tue, Nov 13, 2018 at 8:59 PM, Daniel Eischen  
wrote:

Greetings,

I'm trying to track down a couple of things.  amdtemp doesn't
report any temperature sensors, and acpi seems to have some
errors.  Not sure if they are related.

These are the ACPI-related warnings and errors during boot.

   Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has 
valid Length but zero Address: 0x/0x1 
(20181031/tbfadt-796)


I see this one on my R7 1700 / X370 system, seems harmless.


   acpi0:  on motherboard
   Firmware Error (ACPI): Failure creating [\134_SB.SMIC], 
AE_ALREADY_EXISTS (20181031/dswload2-477)
   ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog 
(20181031/psobject-372)
   Firmware Error (ACPI): Failure creating [\134_SB.SMIB], 
AE_ALREADY_EXISTS (20181031/dsfield-803)


Looks like people see these on Linux:

https://forum.manjaro.org/t/unstable-behaviour-not-always-completely-booting/55823/5

Are you on the latest firmware ("BIOS") revision for your board?

___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Daniel Eischen]

On Tue, 13 Nov 2018, Greg V wrote:




On Tue, Nov 13, 2018 at 8:59 PM, Daniel Eischen  wrote:

Greetings,

I'm trying to track down a couple of things.  amdtemp doesn't
report any temperature sensors, and acpi seems to have some
errors.  Not sure if they are related.

These are the ACPI-related warnings and errors during boot.

   Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has valid 
Length but zero Address: 0x/0x1 (20181031/tbfadt-796)


I see this one on my R7 1700 / X370 system, seems harmless.


   acpi0:  on motherboard
   Firmware Error (ACPI): Failure creating [\134_SB.SMIC], 
AE_ALREADY_EXISTS (20181031/dswload2-477)
   ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog 
(20181031/psobject-372)
   Firmware Error (ACPI): Failure creating [\134_SB.SMIB], 
AE_ALREADY_EXISTS (20181031/dsfield-803)


Looks like people see these on Linux:

https://forum.manjaro.org/t/unstable-behaviour-not-always-completely-booting/55823/5

Are you on the latest firmware ("BIOS") revision for your board?


Yes, it's an ASUS Prime X-470 PRO, and I'm running with the latest
BIOS from 2018 September 21, version 4024.

  https://www.asus.com/us/Motherboards/PRIME-X470-PRO/HelpDesk_BIOS/

--
DE
___
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: emac g4 1.25 GHz retail model won't boot FreeBSD 12 at all.

[Greg V]

On Mon, Nov 12, 2018 at 11:54 PM, Alex McKeever 
 wrote:
The CD or DVD show up fine in the device selection screen, but it 
won’t even boot the disc. What changed from 11.2 to 12.0 in regards 
to PowerPC Macs that are 32 bit?


I've been able to boot various 12-CURRENT builds on my iBook G4 just 
fine.


What exactly do you mean by "won't even boot"? Do you see the loader 
prompt when selecting the disc?


___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Stefan Ehmann]

On 11/13/18 8:59 PM, Daniel Eischen wrote:
> On Tue, 13 Nov 2018, Greg V wrote:
> 
>>
>>
>> On Tue, Nov 13, 2018 at 8:59 PM, Daniel Eischen 
>> wrote:
>>> Greetings,
>>>
>>> I'm trying to track down a couple of things.  amdtemp doesn't
>>> report any temperature sensors, and acpi seems to have some
>>> errors.  Not sure if they are related.
>>>
>>> These are the ACPI-related warnings and errors during boot.
>>>
>>>    Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has
>>> valid Length but zero Address: 0x/0x1
>>> (20181031/tbfadt-796)
>>
>> I see this one on my R7 1700 / X370 system, seems harmless.

I also see this warning on the X470-pro with Ryzen 7 2700 on 12.0-BETA.
But I don't get the Firmware errors below.

>>>    acpi0:  on motherboard
>>>    Firmware Error (ACPI): Failure creating [\134_SB.SMIC],
>>> AE_ALREADY_EXISTS (20181031/dswload2-477)
>>>    ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog
>>> (20181031/psobject-372)
>>>    Firmware Error (ACPI): Failure creating [\134_SB.SMIB],
>>> AE_ALREADY_EXISTS (20181031/dsfield-803)
>>
>> Looks like people see these on Linux:
>>
>> https://forum.manjaro.org/t/unstable-behaviour-not-always-completely-booting/55823/5
>>
>>
>> Are you on the latest firmware ("BIOS") revision for your board?
> 
> Yes, it's an ASUS Prime X-470 PRO, and I'm running with the latest
> BIOS from 2018 September 21, version 4024.
> 
>   https://www.asus.com/us/Motherboards/PRIME-X470-PRO/HelpDesk_BIOS/
> 

After kldload amdtemp I see the following sysctls:
dev.cpu.0.temperature: 77.1C
dev.amdtemp.0.core0.sensor0: 77.1C

The temperature I see in BIOS is much lower (maybe around 40.0C). Don't
know if just the offset is wrong or the numbers are completely bogus.

Numbers from sysutils/xmbmon look saner but not sure if they are correct.
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

On Tue, Nov 13, 2018 at 1:04 PM Stefan Ehmann  wrote:
> After kldload amdtemp I see the following sysctls:
> dev.cpu.0.temperature: 77.1C
> dev.amdtemp.0.core0.sensor0: 77.1C
>
> The temperature I see in BIOS is much lower (maybe around 40.0C). Don't
> know if just the offset is wrong or the numbers are completely bogus.
>
> Numbers from sysutils/xmbmon look saner but not sure if they are correct.

You can adjust dev.amdtemp.N.sensor_offset as needed.  By default, the
amdtemp sysctl gives you the unadjusted value.  On different Ryzen
models the raw value is wrong by different amounts.  E.g. on my 1950X,
I have sensor_offset set to "-27" to show correct temperature
readings.

See this link for a table of offset values for various Ryzen models:
https://www.guru3d.com/articles-pages/amd-ryzen-7-2700-review,7.html

Take care,
Conrad
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Daniel Eischen]

> On Nov 13, 2018, at 4:02 PM, Stefan Ehmann  wrote:
> 
>> On 11/13/18 8:59 PM, Daniel Eischen wrote:
>>> On Tue, 13 Nov 2018, Greg V wrote:
>>> 
>>> 
>>> 
>>> On Tue, Nov 13, 2018 at 8:59 PM, Daniel Eischen 
>>> wrote:
 Greetings,
 
 I'm trying to track down a couple of things.  amdtemp doesn't
 report any temperature sensors, and acpi seems to have some
 errors.  Not sure if they are related.
 
 These are the ACPI-related warnings and errors during boot.
 
Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has
 valid Length but zero Address: 0x/0x1
 (20181031/tbfadt-796)
>>> 
>>> I see this one on my R7 1700 / X370 system, seems harmless.
> 
> I also see this warning on the X470-pro with Ryzen 7 2700 on 12.0-BETA.
> But I don't get the Firmware errors below.

What BIOS version are you using?  I'm running 13-current built from just a few 
days ago.  Never had any temp sysctls since initial install (beginning of 
October).

acpi0:  on motherboard
Firmware Error (ACPI): Failure creating [\134_SB.SMIC],
 AE_ALREADY_EXISTS (20181031/dswload2-477)
ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog
 (20181031/psobject-372)
Firmware Error (ACPI): Failure creating [\134_SB.SMIB],
 AE_ALREADY_EXISTS (20181031/dsfield-803)
>>> 
>>> Looks like people see these on Linux:
>>> 
>>> https://forum.manjaro.org/t/unstable-behaviour-not-always-completely-booting/55823/5
>>> 
>>> 
>>> Are you on the latest firmware ("BIOS") revision for your board?
>> 
>> Yes, it's an ASUS Prime X-470 PRO, and I'm running with the latest
>> BIOS from 2018 September 21, version 4024.
>> 
>>   https://www.asus.com/us/Motherboards/PRIME-X470-PRO/HelpDesk_BIOS/
>> 
> 
> After kldload amdtemp I see the following sysctls:
> dev.cpu.0.temperature: 77.1C
> dev.amdtemp.0.core0.sensor0: 77.1C
> 
> The temperature I see in BIOS is much lower (maybe around 40.0C). Don't
> know if just the offset is wrong or the numbers are completely bogus.
> 
> Numbers from sysutils/xmbmon look saner but not sure if they are correct.

Yeah, I don't have any sensors detected, but my BIOS reports around 39C, right 
around the same as yours.  There are both motherboard and CPU temps in BIOS, 
reporting just a couple of degrees difference.

Overall, this system is very stable, haven't had any crashes or hangs.

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

Hole-punching, TRIM, etc

[Alan Somers]

Hole-punching has been discussed on these lists before[1].  It basically
means to turn a dense file into a sparse file by deallocating storage for
some of the blocks in the middle.  There's no standard API for it.  Linux
uses fallocate(2); Solaris and OSX add a new opcode to fcntl(2).

A related concept is telling a block device that some blocks are no longer
used.  SATA calls this "TRIM", SCSI calls it "UNMAP", NVMe calls it
"Deallocate", ZBC and ZAC call it "Reset Write Pointer".  They all do
basically the same thing, and it's analogous to hole-punching for regular
files.  They are also all inaccessible from FreeBSD's userland except by
using pass(4), which is inconvenient and protocol-specific.

Linux has a BLKDISCARD ioctl for issuing TRIM-like commands from userland,
but it's totally undocumented and doesn't work on regular files.

I propose adding support for all of these things using the fcntl(2) API.
Using the same syntax that Solaris defined, you would be able to punch a
hole in a regular file or TRIM blocks from an SSD.  ZFS already supports it
(though FreeBSD's port never did, and the code was deleted in r303763).
Here's what I would do:

1) Add the F_FREESP command to fcntl(2).
2) Add a .fo_space field for struct fileops
3) Add a devfs_space method that implements .fo_space
4) Add a .d_space field to struct cdevsw
5) Add a g_dev_space method for GEOM that implements .d_space using
BIO_DELETE.
6) Add a VOP_SPACE vop
7) Implement VOP_SPACE for tmpfs
8) Add aio_freesp(2), an asynchronous version of fcntl(F_FREESP).

The greatest beneficiaries of this work would be type 2 hypervisors like
QEMU and VirtualBox with guests that use TRIM, and userland filesystems
such as fusefs-ext2 and fusefs-exfat.  High-performance storage systems
using SPDK would also benefit.  The last item, aio_freesp(2), may seem
unnecessary but it would really benefit my application.

Questions, objections, flames?

-Alan

[1] https://lists.freebsd.org/pipermail/freebsd-fs/2011-March/010881.html
___
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: Hole-punching, TRIM, etc

[Warner Losh]

On Tue, Nov 13, 2018 at 3:10 PM Alan Somers  wrote:

> Hole-punching has been discussed on these lists before[1].  It basically
> means to turn a dense file into a sparse file by deallocating storage for
> some of the blocks in the middle.  There's no standard API for it.  Linux
> uses fallocate(2); Solaris and OSX add a new opcode to fcntl(2).
>
> A related concept is telling a block device that some blocks are no longer
> used.  SATA calls this "TRIM", SCSI calls it "UNMAP", NVMe calls it
> "Deallocate", ZBC and ZAC call it "Reset Write Pointer".  They all do
> basically the same thing, and it's analogous to hole-punching for regular
> files.  They are also all inaccessible from FreeBSD's userland except by
> using pass(4), which is inconvenient and protocol-specific.
>
> Linux has a BLKDISCARD ioctl for issuing TRIM-like commands from userland,
> but it's totally undocumented and doesn't work on regular files.
>
> I propose adding support for all of these things using the fcntl(2) API.
> Using the same syntax that Solaris defined, you would be able to punch a
> hole in a regular file or TRIM blocks from an SSD.  ZFS already supports it
> (though FreeBSD's port never did, and the code was deleted in r303763).
> Here's what I would do:
>
> 1) Add the F_FREESP command to fcntl(2).
> 2) Add a .fo_space field for struct fileops
> 3) Add a devfs_space method that implements .fo_space
> 4) Add a .d_space field to struct cdevsw
> 5) Add a g_dev_space method for GEOM that implements .d_space using
> BIO_DELETE.
> 6) Add a VOP_SPACE vop
> 7) Implement VOP_SPACE for tmpfs
> 8) Add aio_freesp(2), an asynchronous version of fcntl(F_FREESP).
>
> The greatest beneficiaries of this work would be type 2 hypervisors like
> QEMU and VirtualBox with guests that use TRIM, and userland filesystems
> such as fusefs-ext2 and fusefs-exfat.  High-performance storage systems
> using SPDK would also benefit.  The last item, aio_freesp(2), may seem
> unnecessary but it would really benefit my application.
>
> Questions, objections, flames?
>

So the fcntl would deallocate blocks from a filesystem only. The filesystem
may issue BIO_DELETE as a result, but that's up to the filesystem, correct?

On a raw device it would be translated into a BIO_DELETE command directly,
correct?

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"

Re: Hole-punching, TRIM, etc

[Conrad Meyer]

Hi Alan,

On Tue, Nov 13, 2018 at 2:10 PM Alan Somers  wrote:
>
> Hole-punching has been discussed on these lists before[1].  It basically
> means to turn a dense file into a sparse file by deallocating storage for
> some of the blocks in the middle.  There's no standard API for it.  Linux
> uses fallocate(2); Solaris and OSX add a new opcode to fcntl(2).
>
> A related concept is telling a block device that some blocks are no longer
> used.  SATA calls this "TRIM", SCSI calls it "UNMAP", NVMe calls it
> "Deallocate", ZBC and ZAC call it "Reset Write Pointer".  They all do
> basically the same thing, and it's analogous to hole-punching for regular
> files.  They are also all inaccessible from FreeBSD's userland except by
> using pass(4), which is inconvenient and protocol-specific.

Geom devices have the DIOCGDELETE ioctl, which translates into
BIO_DELETE (which is TRIM, as I understand it).  It's available in
libgeom as g_delete() and used by hastd, newfs_nandfs, and nandtool.

> Linux has a BLKDISCARD ioctl for issuing TRIM-like commands from userland,
> but it's totally undocumented and doesn't work on regular files.
>
> I propose adding support for all of these things using the fcntl(2) API.
> Using the same syntax that Solaris defined, you would be able to punch a
> hole in a regular file or TRIM blocks from an SSD.  ZFS already supports it
> (though FreeBSD's port never did, and the code was deleted in r303763).
> Here's what I would do:
>
> 1) Add the F_FREESP command to fcntl(2).
> 2) Add a .fo_space field for struct fileops
> 3) Add a devfs_space method that implements .fo_space
> 4) Add a .d_space field to struct cdevsw
> 5) Add a g_dev_space method for GEOM that implements .d_space using
> BIO_DELETE.
> 6) Add a VOP_SPACE vop
> 7) Implement VOP_SPACE for tmpfs
> 8) Add aio_freesp(2), an asynchronous version of fcntl(F_FREESP).

Why not just add DIOCGDELETE support to various VOP_IOCTL
implementations?  The file objects forward correctly through vn_ioctl
to VOP_IOCTL for both regular files and devfs VCHR nodes.

We can emulate the Linux API if we want to be compatible there, but I
wouldn't bother with Solaris.

Best,
Conrad
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Rozhuk Ivan]

On Tue, 13 Nov 2018 13:14:46 -0800
Conrad Meyer  wrote:

> You can adjust dev.amdtemp.N.sensor_offset as needed.  By default, the
> amdtemp sysctl gives you the unadjusted value.  On different Ryzen
> models the raw value is wrong by different amounts.  E.g. on my 1950X,
> I have sensor_offset set to "-27" to show correct temperature
> readings.
> 

Looks like new AGESA/BIOS change something, my fork of amdtemp now show (read) 
same value as on onboard led in "CurTmpTjSel"
...
dev.amdtemp.0.rtc.CurTmpTjSel: 47.7C
dev.amdtemp.0.rtc.CurTmp: 96.7C
...
49C diff, this was some sort of offset for older AMD CPU, used to calc 
CurTmpTjSel then it set to 3.
___
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: Hole-punching, TRIM, etc

[Alan Somers]

On Tue, Nov 13, 2018 at 3:51 PM Conrad Meyer  wrote:

> Hi Alan,
>
> On Tue, Nov 13, 2018 at 2:10 PM Alan Somers  wrote:
> >
> > Hole-punching has been discussed on these lists before[1].  It basically
> > means to turn a dense file into a sparse file by deallocating storage for
> > some of the blocks in the middle.  There's no standard API for it.  Linux
> > uses fallocate(2); Solaris and OSX add a new opcode to fcntl(2).
> >
> > A related concept is telling a block device that some blocks are no
> longer
> > used.  SATA calls this "TRIM", SCSI calls it "UNMAP", NVMe calls it
> > "Deallocate", ZBC and ZAC call it "Reset Write Pointer".  They all do
> > basically the same thing, and it's analogous to hole-punching for regular
> > files.  They are also all inaccessible from FreeBSD's userland except by
> > using pass(4), which is inconvenient and protocol-specific.
>
> Geom devices have the DIOCGDELETE ioctl, which translates into
> BIO_DELETE (which is TRIM, as I understand it).  It's available in
> libgeom as g_delete() and used by hastd, newfs_nandfs, and nandtool.
>

Ahh, I thought there must be such a thing, but I couldn't find it.


>
> > Linux has a BLKDISCARD ioctl for issuing TRIM-like commands from
> userland,
> > but it's totally undocumented and doesn't work on regular files.
> >
> > I propose adding support for all of these things using the fcntl(2) API.
> > Using the same syntax that Solaris defined, you would be able to punch a
> > hole in a regular file or TRIM blocks from an SSD.  ZFS already supports
> it
> > (though FreeBSD's port never did, and the code was deleted in r303763).
> > Here's what I would do:
> >
> > 1) Add the F_FREESP command to fcntl(2).
> > 2) Add a .fo_space field for struct fileops
> > 3) Add a devfs_space method that implements .fo_space
> > 4) Add a .d_space field to struct cdevsw
> > 5) Add a g_dev_space method for GEOM that implements .d_space using
> > BIO_DELETE.
> > 6) Add a VOP_SPACE vop
> > 7) Implement VOP_SPACE for tmpfs
> > 8) Add aio_freesp(2), an asynchronous version of fcntl(F_FREESP).
>
> Why not just add DIOCGDELETE support to various VOP_IOCTL
> implementations?  The file objects forward correctly through vn_ioctl
> to VOP_IOCTL for both regular files and devfs VCHR nodes.
>
> We can emulate the Linux API if we want to be compatible there, but I
> wouldn't bother with Solaris.
>

The only reason that I prefer the Solaris API is because it doesn't require
adding another syscall, and because Linux's fallocate(2) does a whole bunch
of other things besides hole-punching.

What about an asynchronous version?  ioctl(2) is still synchronous.  Do you
see any better way to hole-punch/TRIM asynchronously than with aio?


>
> Best,
> Conrad
>
___
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: Hole-punching, TRIM, etc

[Alan Somers]

On Tue, Nov 13, 2018 at 3:51 PM Warner Losh  wrote:

>
>
> On Tue, Nov 13, 2018 at 3:10 PM Alan Somers  wrote:
>
>> Hole-punching has been discussed on these lists before[1].  It basically
>> means to turn a dense file into a sparse file by deallocating storage for
>> some of the blocks in the middle.  There's no standard API for it.  Linux
>> uses fallocate(2); Solaris and OSX add a new opcode to fcntl(2).
>>
>> A related concept is telling a block device that some blocks are no longer
>> used.  SATA calls this "TRIM", SCSI calls it "UNMAP", NVMe calls it
>> "Deallocate", ZBC and ZAC call it "Reset Write Pointer".  They all do
>> basically the same thing, and it's analogous to hole-punching for regular
>> files.  They are also all inaccessible from FreeBSD's userland except by
>> using pass(4), which is inconvenient and protocol-specific.
>>
>> Linux has a BLKDISCARD ioctl for issuing TRIM-like commands from userland,
>> but it's totally undocumented and doesn't work on regular files.
>>
>> I propose adding support for all of these things using the fcntl(2) API.
>> Using the same syntax that Solaris defined, you would be able to punch a
>> hole in a regular file or TRIM blocks from an SSD.  ZFS already supports
>> it
>> (though FreeBSD's port never did, and the code was deleted in r303763).
>> Here's what I would do:
>>
>> 1) Add the F_FREESP command to fcntl(2).
>> 2) Add a .fo_space field for struct fileops
>> 3) Add a devfs_space method that implements .fo_space
>> 4) Add a .d_space field to struct cdevsw
>> 5) Add a g_dev_space method for GEOM that implements .d_space using
>> BIO_DELETE.
>> 6) Add a VOP_SPACE vop
>> 7) Implement VOP_SPACE for tmpfs
>> 8) Add aio_freesp(2), an asynchronous version of fcntl(F_FREESP).
>>
>> The greatest beneficiaries of this work would be type 2 hypervisors like
>> QEMU and VirtualBox with guests that use TRIM, and userland filesystems
>> such as fusefs-ext2 and fusefs-exfat.  High-performance storage systems
>> using SPDK would also benefit.  The last item, aio_freesp(2), may seem
>> unnecessary but it would really benefit my application.
>>
>> Questions, objections, flames?
>>
>
> So the fcntl would deallocate blocks from a filesystem only. The
> filesystem may issue BIO_DELETE as a result, but that's up to the
> filesystem, correct?
>

Correct.


>
> On a raw device it would be translated into a BIO_DELETE command directly,
> correct?
>

Correct, modulo edge cases.


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

Re: Hole-punching, TRIM, etc

[Warner Losh]

On Tue, Nov 13, 2018 at 3:52 PM Conrad Meyer  wrote:

> Geom devices have the DIOCGDELETE ioctl, which translates into
> BIO_DELETE (which is TRIM, as I understand it).
>

Correct. TRIM is both the catch-all term people use, as well as the name of
a specific DSM (data set management) command in the ATA command set. All
FLASH technologies have it (thought what it means under the covers varies a
bit). Thin provisioned resources like in VMs also have it.

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"

Re: Hole-punching, TRIM, etc

[Poul-Henning Kamp]

In message 
, Warner Losh writes:

>On a raw device it would be translated into a BIO_DELETE command directly,
>correct?

We already have ioctl(DIOCGDELETE) for that.  newfs(8) uses it.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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: Hole-punching, TRIM, etc

[Conrad Meyer]

On Tue, Nov 13, 2018 at 2:59 PM Alan Somers  wrote:
>
> On Tue, Nov 13, 2018 at 3:51 PM Conrad Meyer  wrote:
>>
>> On Tue, Nov 13, 2018 at 2:10 PM Alan Somers  wrote:
>> > ...
>> > 8) Add aio_freesp(2), an asynchronous version of fcntl(F_FREESP).
>>
>> Why not just add DIOCGDELETE support to various VOP_IOCTL
>> implementations?  The file objects forward correctly through vn_ioctl
>> to VOP_IOCTL for both regular files and devfs VCHR nodes.
>>
>> We can emulate the Linux API if we want to be compatible there, but I
>> wouldn't bother with Solaris.
>
> The only reason that I prefer the Solaris API is because it doesn't require 
> adding another syscall, and because Linux's fallocate(2) does a whole bunch 
> of other things besides hole-punching.

I am imagining that if we went this route, we would implement Linux
fallocate as a library shim around the native FreeBSD ioctl (or
whatever) rather than an independent system call.  This would be for
API compatibility, not ABI compatibility.  But Linux compat can be set
aside for now, I think — it's a secondary concern.

> What about an asynchronous version?  ioctl(2) is still synchronous.  Do you 
> see any better way to hole-punch/TRIM asynchronously than with aio?

Yeah, this is a good consideration.  No, I don't have any better
suggestion for an asynchronous API.  In general our VOPs tend to be
synchronous.  Aio does seem like the logical home for a new
asynchronous API.

Best regards,
Conrad
___
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: UEFI GOP: screen goes blank during boot after loader is finished

[Subbsd]

Hi,



On Tue, Nov 13, 2018 at 7:22 PM Rodney W. Grimes
 wrote:
>
> Uh oh, ok, thats not what I was thinking of then.  I do not have any
> bhyve capable hardware running on 12BETA at this time to test with.
>
> I wonder if we have a bad interaction between the loader and
> bhyve again, we have had a few of those.
>

it's broken before 12-ALPHA1, my post from 14-Sep to current@

https://lists.freebsd.org/pipermail/freebsd-current/2018-September/071206.html

probably the lua loader doesn't understand efifb/term very well
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Stefan Ehmann]

On 11/13/18 10:40 PM, Daniel Eischen wrote:
> 
>> On Nov 13, 2018, at 4:02 PM, Stefan Ehmann  wrote:
>>
>>> On 11/13/18 8:59 PM, Daniel Eischen wrote:
 On Tue, 13 Nov 2018, Greg V wrote:



 On Tue, Nov 13, 2018 at 8:59 PM, Daniel Eischen 
 wrote:
> Greetings,
>
> I'm trying to track down a couple of things.  amdtemp doesn't
> report any temperature sensors, and acpi seems to have some
> errors.  Not sure if they are related.
>
> These are the ACPI-related warnings and errors during boot.
>
>Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has
> valid Length but zero Address: 0x/0x1
> (20181031/tbfadt-796)

 I see this one on my R7 1700 / X370 system, seems harmless.
>>
>> I also see this warning on the X470-pro with Ryzen 7 2700 on 12.0-BETA.
>> But I don't get the Firmware errors below.
> 
> What BIOS version are you using?  I'm running 13-current built from just a 
> few days ago.  Never had any temp sysctls since initial install (beginning of 
> October).

Latest Version (4024), but I think I've tried it before with an older
version. Didn't notice any differences though.

But I guess amdtemp is more dependent on the CPU than on the main board.
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Stefan Ehmann]

On 11/13/18 10:14 PM, Conrad Meyer wrote:
> On Tue, Nov 13, 2018 at 1:04 PM Stefan Ehmann  wrote:
>> After kldload amdtemp I see the following sysctls:
>> dev.cpu.0.temperature: 77.1C
>> dev.amdtemp.0.core0.sensor0: 77.1C
>>
>> The temperature I see in BIOS is much lower (maybe around 40.0C). Don't
>> know if just the offset is wrong or the numbers are completely bogus.
>>
>> Numbers from sysutils/xmbmon look saner but not sure if they are correct.
> 
> You can adjust dev.amdtemp.N.sensor_offset as needed.  By default, the
> amdtemp sysctl gives you the unadjusted value.  On different Ryzen
> models the raw value is wrong by different amounts.  E.g. on my 1950X,
> I have sensor_offset set to "-27" to show correct temperature
> readings.
> 
> See this link for a table of offset values for various Ryzen models:
> https://www.guru3d.com/articles-pages/amd-ryzen-7-2700-review,7.html

Thanks for the link.

The 2700 has an offset of 0 though (2700X has 10).
And I'm seeing a difference of more than 30 degrees. I guess something
else must be happening here.
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Daniel Eischen]

> On Nov 13, 2018, at 2:06 PM, Rozhuk Ivan  wrote:
> 
> On Tue, 13 Nov 2018 12:59:59 -0500 (EST)
> Daniel Eischen  wrote:
> 
>> I'm trying to track down a couple of things.  amdtemp doesn't
>> report any temperature sensors, and acpi seems to have some
>> errors.  Not sure if they are related.
> 
> It s a bit legacy )
> Try mine: http://www.netlab.linkpc.net/download/tmp/amdtemp.c
> does not use amdsmn.

Thanks, I think?!  I tried it and it panic'd as soon as it was kldload'd.  I 
don't have the trace back handy, but it was in a mtx lock after a pci_write.  
I'm running 13-current, so it could be something different between that and 
-stable or whatever you're testing it on.

--
DE
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

Hi Daniel,

On Tue, Nov 13, 2018 at 10:01 AM Daniel Eischen  wrote:
>
> Greetings,
>
> I'm trying to track down a couple of things.  amdtemp doesn't
> report any temperature sensors, and acpi seems to have some
> errors.  Not sure if they are related.

Maybe not.  If they do not attach, it suggests that maybe the Ryzen 2
has a different hostbridge PCI devid.

> ...
> The amdtemp module loads fine (including the dependent amdsmn), but
> doesn't report any temperature related sysctls.

Can you run 'devinfo -v' and send or paste the output?  Thank you.

All the best,
Conrad
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Rozhuk Ivan]

On Tue, 13 Nov 2018 19:41:47 -0500
Daniel Eischen  wrote:

> >> I'm trying to track down a couple of things.  amdtemp doesn't
> >> report any temperature sensors, and acpi seems to have some
> >> errors.  Not sure if they are related.  
> > 
> > It s a bit legacy )
> > Try mine: http://www.netlab.linkpc.net/download/tmp/amdtemp.c
> > does not use amdsmn.  
> 
> Thanks, I think?!  I tried it and it panic'd as soon as it was
> kldload'd.  I don't have the trace back handy, but it was in a mtx
> lock after a pci_write.  I'm running 13-current, so it could be
> something different between that and -stable or whatever you're
> testing it on.


I do not test it on 13.
Make sure that you have not amdtemp and amdsmn built in kernel and that they 
not loaded.
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

On Tue, Nov 13, 2018 at 5:15 PM Rozhuk Ivan  wrote:
>
> On Tue, 13 Nov 2018 19:41:47 -0500
> Daniel Eischen  wrote:
>
> > >> I'm trying to track down a couple of things.  amdtemp doesn't
> > >> report any temperature sensors, and acpi seems to have some
> > >> errors.  Not sure if they are related.
> > >
> > > It s a bit legacy )
> > > Try mine: http://www.netlab.linkpc.net/download/tmp/amdtemp.c
> > > does not use amdsmn.
> >
> > Thanks, I think?!  I tried it and it panic'd as soon as it was
> > kldload'd.  I don't have the trace back handy, but it was in a mtx
> > lock after a pci_write.  I'm running 13-current, so it could be
> > something different between that and -stable or whatever you're
> > testing it on.
>
>
> I do not test it on 13.
> Make sure that you have not amdtemp and amdsmn built in kernel and that they 
> not loaded.

Your amdtemp_rtc_temp_sysctl has a lock recursion bug and any
INVARIANTS kernel will panic running it.
___
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: UEFI GOP: screen goes blank during boot after loader is finished

[Kyle Evans]

On Tue, Nov 13, 2018 at 5:15 PM Subbsd  wrote:
>
> Hi,
>
>
>
> On Tue, Nov 13, 2018 at 7:22 PM Rodney W. Grimes
>  wrote:
> >
> > Uh oh, ok, thats not what I was thinking of then.  I do not have any
> > bhyve capable hardware running on 12BETA at this time to test with.
> >
> > I wonder if we have a bad interaction between the loader and
> > bhyve again, we have had a few of those.
> >
>
> it's broken before 12-ALPHA1, my post from 14-Sep to current@
>
> https://lists.freebsd.org/pipermail/freebsd-current/2018-September/071206.html
>
> probably the lua loader doesn't understand efifb/term very well

These things are basically completely unrelated- the interpreter
included in loader(8) doesn't have to know anything about graphics and
this stuff is handled before and after the interpreter is invoked.

However, because loader-land is funny in a not-ha-ha kind of way, can
you try replacing loader.efi on your guest VM with the Forth-flavored
version to rule that out or narrow it down, please?

Thanks,

Kyle Evans
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Daniel Eischen]

On Tue, 13 Nov 2018, Conrad Meyer wrote:


Hi Daniel,

On Tue, Nov 13, 2018 at 10:01 AM Daniel Eischen  wrote:


Greetings,

I'm trying to track down a couple of things.  amdtemp doesn't
report any temperature sensors, and acpi seems to have some
errors.  Not sure if they are related.


Maybe not.  If they do not attach, it suggests that maybe the Ryzen 2
has a different hostbridge PCI devid.


...
The amdtemp module loads fine (including the dependent amdsmn), but
doesn't report any temperature related sysctls.


Can you run 'devinfo -v' and send or paste the output?  Thank you.


I've attached it.  If it gets filtered by the mail list, I'll
make it http accessible.

--
DEnexus0
  cryptosoft0
  vtvga0
  apic0
  ram0
  acpi0
cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.P000
  acpi_perf0
  hwpstate0
  acpi_throttle0
  cpufreq0
cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.P001
  acpi_perf1
  hwpstate1
  acpi_throttle1
cpu2 pnpinfo _HID=none _UID=0 at handle=\_PR_.P002
  acpi_perf2
  hwpstate2
  acpi_throttle2
cpu3 pnpinfo _HID=none _UID=0 at handle=\_PR_.P003
  acpi_perf3
  hwpstate3
  acpi_throttle3
cpu4 pnpinfo _HID=none _UID=0 at handle=\_PR_.P004
  acpi_perf4
  hwpstate4
  acpi_throttle4
cpu5 pnpinfo _HID=none _UID=0 at handle=\_PR_.P005
  acpi_perf5
  hwpstate5
  acpi_throttle5
cpu6 pnpinfo _HID=none _UID=0 at handle=\_PR_.P006
  acpi_perf6
  hwpstate6
  acpi_throttle6
cpu7 pnpinfo _HID=none _UID=0 at handle=\_PR_.P007
  acpi_perf7
  hwpstate7
  acpi_throttle7
unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.P008
unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.P009
unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.P00A
unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.P00B
unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.P00C
unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.P00D
unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.P00E
unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.P00F
pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0
  pci0
hostb0 pnpinfo vendor=0x1022 device=0x15d0 subvendor=0x1043 
subdevice=0x876b class=0x06 at slot=0 function=0 dbsf=pci0:0:0:0 
handle=\_SB_.PCI0.D004
unknown pnpinfo vendor=0x1022 device=0x15d1 subvendor=0x1022 
subdevice=0x15d1 class=0x080600 at slot=0 function=2 dbsf=pci0:0:0:2 
handle=\_SB_.PCI0.IOMA
hostb1 pnpinfo vendor=0x1022 device=0x1452 subvendor=0x 
subdevice=0x class=0x06 at slot=1 function=0 dbsf=pci0:0:1:0
pcib1 pnpinfo vendor=0x1022 device=0x15d3 subvendor=0x1043 
subdevice=0x876b class=0x060400 at slot=1 function=2 dbsf=pci0:0:1:2 
handle=\_SB_.PCI0.GPP1
  pci1
xhci0 pnpinfo vendor=0x1022 device=0x43d0 subvendor=0x1b21 
subdevice=0x1142 class=0x0c0330 at slot=0 function=0 dbsf=pci0:1:0:0 
handle=\_SB_.PCI0.GPP1.PTXH
  usbus0
uhub2
ahci0 pnpinfo vendor=0x1022 device=0x43c8 subvendor=0x1b21 
subdevice=0x1062 class=0x010601 at slot=0 function=1 dbsf=pci0:1:0:1 
handle=\_SB_.PCI0.GPP1.PT01
  ahcich0 at channel=0
  ahcich1 at channel=1
  ahcich2 at channel=2
  ahcich3 at channel=3
  ahcich4 at channel=4
  ahcich5 at channel=5
  ahcich6 at channel=6
  ahcich7 at channel=7
pcib2 pnpinfo vendor=0x1022 device=0x43c6 subvendor=0x1b21 
subdevice=0x0201 class=0x060400 at slot=0 function=2 dbsf=pci0:1:0:2 
handle=\_SB_.PCI0.GPP1.PT02
  pci2
pcib3 pnpinfo vendor=0x1022 device=0x43c7 subvendor=0x1b21 
subdevice=0x3306 class=0x060400 at slot=0 function=0 dbsf=pci0:2:0:0 
handle=\_SB_.PCI0.GPP1.PT02.PT20
  pci3
pcib4 pnpinfo vendor=0x1022 device=0x43c7 subvendor=0x1b21 
subdevice=0x3306 class=0x060400 at slot=4 function=0 dbsf=pci0:2:4:0 
handle=\_SB_.PCI0.GPP1.PT02.PT24
  pci4
xhci1 pnpinfo vendor=0x1b21 device=0x1242 subvendor=0x1043 
subdevice=0x8675 class=0x0c0330 at slot=0 function=0 dbsf=pci0:4:0:0 
handle=\_SB_.PCI0.GPP1.PT02.PT24.AS42
  usbus1
uhub0
  ukbd0 pnpinfo vendor=0x046d product=0xc31c 
devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x6400 mode=host 
intclass=0x03 intsubclass=0x01 intprotocol=0x01 at bus=1 hubaddr=1 port=3 
devaddr=2 interface=0 ugen=ugen1.2
  uhid0 pnpinfo vendor=0x046d product=0xc31c 
devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x6400 mode=host 
intclass=0x03 intsubclass=0x00 intprotocol=0x00 at bus=1 hubaddr=1 port=3 
devaddr=2 interface=1 ugen=ugen1.2
  ums0 pnpinfo vendor=0x046d product=0xc014 
devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x0340 mode=host 
intclass=0x03 intsubclass=0x

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

On Tue, Nov 13, 2018 at 6:26 PM Daniel Eischen  wrote:
> I've attached it.  If it gets filtered by the mail list, I'll
> make it http accessible.

Thanks Daniel.

It looks like your hostbridge zero device has a different device id
than in my first generation Ryzen system.  Would you please try the
following patch and see if it attaches on your system?  I don't
actually have documentation for Ryzen 2, unfortunately, so I'm not
totally sure if the SMN is accessed in the same way for the new
hostbridge device id.  The change below should at least attempt
attaching to hostb0 on your system.

diff --git a/sys/dev/amdsmn/amdsmn.c b/sys/dev/amdsmn/amdsmn.c
index 17792dd922cd..6fe36b4cc4da 100644
--- a/sys/dev/amdsmn/amdsmn.c
+++ b/sys/dev/amdsmn/amdsmn.c
@@ -60,7 +60,8 @@ struct amdsmn_softc {
 static struct pciid {
uint32_tdevice_id;
 } amdsmn_ids[] = {
-   { 0x14501022 },
+   { 0x14501022 }, /* Ryzen */
+   { 0x15d01022 }, /* Ryzen 2 */
 };

 /*
diff --git a/sys/dev/amdtemp/amdtemp.c b/sys/dev/amdtemp/amdtemp.c
index 2463212c25f5..765e660a8461 100644
--- a/sys/dev/amdtemp/amdtemp.c
+++ b/sys/dev/amdtemp/amdtemp.c
@@ -102,6 +102,7 @@ static struct amdtemp_product {
{ VENDORID_AMD, DEVICEID_AMD_MISC16_M30H },
{ VENDORID_AMD, DEVICEID_AMD_MISC17 },
{ VENDORID_AMD, DEVICEID_AMD_HOSTB17H },
+   { VENDORID_AMD, 0x15d0 },
 };

 /*


Thanks,
Conrad
___
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"

[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)

[bugzilla-noreply]

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

Kubilay Kocak  changed:

   What|Removed |Added

Summary|Cannot check battery status |Cannot check battery status
   |after upgrading to  |after upgrading to
   |12-CURRENT after r330957|12-CURRENT after r330957
   |(ACPI problems) |(ACPI _STA method removed)
 CC||curr...@freebsd.org

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

Of course, Johannes has already thought of this!  See
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228480 and
https://reviews.freebsd.org/D15567 .
On Tue, Nov 13, 2018 at 6:41 PM Conrad Meyer  wrote:
>
> On Tue, Nov 13, 2018 at 6:26 PM Daniel Eischen  wrote:
> > I've attached it.  If it gets filtered by the mail list, I'll
> > make it http accessible.
>
> Thanks Daniel.
>
> It looks like your hostbridge zero device has a different device id
> than in my first generation Ryzen system.  Would you please try the
> following patch and see if it attaches on your system?  I don't
> actually have documentation for Ryzen 2, unfortunately, so I'm not
> totally sure if the SMN is accessed in the same way for the new
> hostbridge device id.  The change below should at least attempt
> attaching to hostb0 on your system.
>
> diff --git a/sys/dev/amdsmn/amdsmn.c b/sys/dev/amdsmn/amdsmn.c
> index 17792dd922cd..6fe36b4cc4da 100644
> --- a/sys/dev/amdsmn/amdsmn.c
> +++ b/sys/dev/amdsmn/amdsmn.c
> @@ -60,7 +60,8 @@ struct amdsmn_softc {
>  static struct pciid {
> uint32_tdevice_id;
>  } amdsmn_ids[] = {
> -   { 0x14501022 },
> +   { 0x14501022 }, /* Ryzen */
> +   { 0x15d01022 }, /* Ryzen 2 */
>  };
>
>  /*
> diff --git a/sys/dev/amdtemp/amdtemp.c b/sys/dev/amdtemp/amdtemp.c
> index 2463212c25f5..765e660a8461 100644
> --- a/sys/dev/amdtemp/amdtemp.c
> +++ b/sys/dev/amdtemp/amdtemp.c
> @@ -102,6 +102,7 @@ static struct amdtemp_product {
> { VENDORID_AMD, DEVICEID_AMD_MISC16_M30H },
> { VENDORID_AMD, DEVICEID_AMD_MISC17 },
> { VENDORID_AMD, DEVICEID_AMD_HOSTB17H },
> +   { VENDORID_AMD, 0x15d0 },
>  };
>
>  /*
>
>
> Thanks,
> Conrad
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Daniel Eischen]

On Tue, 13 Nov 2018, Conrad Meyer wrote:


On Tue, Nov 13, 2018 at 6:26 PM Daniel Eischen  wrote:

I've attached it.  If it gets filtered by the mail list, I'll
make it http accessible.


Thanks Daniel.

It looks like your hostbridge zero device has a different device id
than in my first generation Ryzen system.  Would you please try the
following patch and see if it attaches on your system?  I don't
actually have documentation for Ryzen 2, unfortunately, so I'm not
totally sure if the SMN is accessed in the same way for the new
hostbridge device id.  The change below should at least attempt
attaching to hostb0 on your system.


That seems to have done the trick, thanks!  Output
attached.

--
 DEnet.inet6.ip6.use_tempaddr: 0
net.inet6.ip6.temppltime: 86400
net.inet6.ip6.tempvltime: 604800
net.inet6.ip6.prefer_tempaddr: 0
hw.usb.template: -1
kstat.zfs.misc.arcstats.arc_tempreserve: 0
kstat.zfs.misc.zcompstats.attempts: 18438
dev.amdtemp.0.core0.sensor0: 28.1C
dev.amdtemp.0.sensor_offset: 0
dev.amdtemp.0.%parent: hostb0
dev.amdtemp.0.%pnpinfo: 
dev.amdtemp.0.%location: 
dev.amdtemp.0.%driver: amdtemp
dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors
dev.amdtemp.%parent: 
dev.cpu.7.temperature: 28.1C
dev.cpu.6.temperature: 28.1C
dev.cpu.5.temperature: 28.1C
dev.cpu.4.temperature: 28.1C
dev.cpu.3.temperature: 28.1C
dev.cpu.2.temperature: 28.1C
dev.cpu.1.temperature: 28.1C
dev.cpu.0.temperature: 28.1C
___
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: UEFI GOP: screen goes blank during boot after loader is finished

[Rebecca Cran]

On Tuesday, 13 November 2018 18:57:25 MST Kyle Evans wrote:

> However, because loader-land is funny in a not-ha-ha kind of way, can
> you try replacing loader.efi on your guest VM with the Forth-flavored
> version to rule that out or narrow it down, please?

That didn't help.
As probably expected, the last output before the screen goes blank is 
framebuffer information:

/boot/kernel/kernel text=0x16776f0 data=0x1cd288+0x768b40 
syms=[0x8+0x174ca8+0x8+0x192218]
Booting...
Start @ 0x80341000 ...
EFI framebuffer information:
addr, size   0xc100, 0x100
dimensions   800 x 600
stride 800
masks  0x00ff, 0xff00, 0x00ff, 0xff00

-- 
Rebecca


___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Rebecca Cran]

On Tuesday, 13 November 2018 16:20:22 MST Stefan Ehmann wrote:

> The 2700 has an offset of 0 though (2700X has 10).
> And I'm seeing a difference of more than 30 degrees. I guess something
> else must be happening here.

I had thought 54 was the right offset for my 2990WX system, but now it's under 
load building ports the temperature reported via dev.amdtemp is 183C! 
Meanwhile the readout on the motherboard says "CPU Temp 53 C".

-- 
Rebecca


___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

On Tue, Nov 13, 2018 at 7:16 PM Daniel Eischen  wrote:
>
> On Tue, 13 Nov 2018, Conrad Meyer wrote:
>
> > On Tue, Nov 13, 2018 at 6:26 PM Daniel Eischen  wrote:
> >> I've attached it.  If it gets filtered by the mail list, I'll
> >> make it http accessible.
> >
> > Thanks Daniel.
> >
> > It looks like your hostbridge zero device has a different device id
> > than in my first generation Ryzen system.  Would you please try the
> > following patch and see if it attaches on your system?  I don't
> > actually have documentation for Ryzen 2, unfortunately, so I'm not
> > totally sure if the SMN is accessed in the same way for the new
> > hostbridge device id.  The change below should at least attempt
> > attaching to hostb0 on your system.
>
> That seems to have done the trick, thanks!  Output
> attached.

Thanks for the quick test!  I've committed Johannes' substantially
similar patch as r340425.

Cheers,
Conrad
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

On Tue, Nov 13, 2018 at 8:05 PM Rebecca Cran  wrote:
>
> On Tuesday, 13 November 2018 16:20:22 MST Stefan Ehmann wrote:
>
> > The 2700 has an offset of 0 though (2700X has 10).
> > And I'm seeing a difference of more than 30 degrees. I guess something
> > else must be happening here.
>
> I had thought 54 was the right offset for my 2990WX system, but now it's under
> load building ports the temperature reported via dev.amdtemp is 183C!
> Meanwhile the readout on the motherboard says "CPU Temp 53 C".

Maybe it should be -54 instead of +54?  183-(54*2) is the somewhat
plausible 75°C (still pretty warm even for load).  How good is your
cooling solution?

(The references I can find with a quick search suggest TR 29xx should
also be -27° rather than -54°C, but they may be mistaken.  183-54-27
is still 102°C — extremely hot!)

Best,
Conrad
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Rebecca Cran]

On Tuesday, 13 November 2018 21:17:59 MST Conrad Meyer wrote:

> Maybe it should be -54 instead of +54?  183-(54*2) is the somewhat
> plausible 75?C (still pretty warm even for load).  How good is your
> cooling solution?

D'oh, of course it's -54 instead of +54 (For some reason I presumed a positive 
offset would be *subtracted*)!   I have an all-in-one liquid thermaltake 
cooler installed, and under Windows it reports reaching 67C when running flat 
out, which doesn't seem bad.

> (The references I can find with a quick search suggest TR 29xx should
> also be -27? rather than -54?C, but they may be mistaken.  183-54-27
> is still 102?C ? extremely hot!)

That's why I thought 54 was more likely! My 2990WX has 4 units for 32 cores 
instead of 2 units and 16 cores for other models, so I guessed that perhaps I 
should double the 27 value other people had said should be used.

-- 
Rebecca


___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

On Tue, Nov 13, 2018 at 8:29 PM Rebecca Cran  wrote:
>
> On Tuesday, 13 November 2018 21:17:59 MST Conrad Meyer wrote:
>
> > Maybe it should be -54 instead of +54?  183-(54*2) is the somewhat
> > plausible 75?C (still pretty warm even for load).  How good is your
> > cooling solution?
>
> D'oh, of course it's -54 instead of +54 (For some reason I presumed a positive
> offset would be *subtracted*)!   I have an all-in-one liquid thermaltake
> cooler installed, and under Windows it reports reaching 67C when running flat
> out, which doesn't seem bad.

Yeah, 67C seems totally great at load.

> > (The references I can find with a quick search suggest TR 29xx should
> > also be -27? rather than -54?C, but they may be mistaken.  183-54-27
> > is still 102?C ? extremely hot!)
>
> That's why I thought 54 was more likely! My 2990WX has 4 units for 32 cores
> instead of 2 units and 16 cores for other models, so I guessed that perhaps I
> should double the 27 value other people had said should be used.

Hm, the Linux folks still use -27 for the 2990WX as well as all of the
other threadripper models.  I'm not sure what's right.  I wish I had
access to the Ryzen 2 register docs, but I don't.

Best,
Conrad
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

You know what, I wonder if you're running into the CUR_TEMP_RANGE_SEL?
 I.e., sometimes the CPU chooses to report on a range from 0-225C and
sometimes -49C-206C.  I think someone else's 2990WX did the same
thing.  I guess that patch never landed?  102°C - 49°C is the very
reasonable 53°C.

Yeah, sigh, it never landed:  https://reviews.freebsd.org/D16855

Ok I'll go ahead and commit that too.

Thanks,
Conrad
On Tue, Nov 13, 2018 at 8:38 PM Conrad Meyer  wrote:
>
> On Tue, Nov 13, 2018 at 8:29 PM Rebecca Cran  wrote:
> >
> > On Tuesday, 13 November 2018 21:17:59 MST Conrad Meyer wrote:
> >
> > > Maybe it should be -54 instead of +54?  183-(54*2) is the somewhat
> > > plausible 75?C (still pretty warm even for load).  How good is your
> > > cooling solution?
> >
> > D'oh, of course it's -54 instead of +54 (For some reason I presumed a 
> > positive
> > offset would be *subtracted*)!   I have an all-in-one liquid thermaltake
> > cooler installed, and under Windows it reports reaching 67C when running 
> > flat
> > out, which doesn't seem bad.
>
> Yeah, 67C seems totally great at load.
>
> > > (The references I can find with a quick search suggest TR 29xx should
> > > also be -27? rather than -54?C, but they may be mistaken.  183-54-27
> > > is still 102?C ? extremely hot!)
> >
> > That's why I thought 54 was more likely! My 2990WX has 4 units for 32 cores
> > instead of 2 units and 16 cores for other models, so I guessed that perhaps 
> > I
> > should double the 27 value other people had said should be used.
>
> Hm, the Linux folks still use -27 for the 2990WX as well as all of the
> other threadripper models.  I'm not sure what's right.  I wish I had
> access to the Ryzen 2 register docs, but I don't.
>
> Best,
> Conrad
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

Please try r340426 :-).
On Tue, Nov 13, 2018 at 8:41 PM Conrad Meyer  wrote:
>
> You know what, I wonder if you're running into the CUR_TEMP_RANGE_SEL?
>  I.e., sometimes the CPU chooses to report on a range from 0-225C and
> sometimes -49C-206C.  I think someone else's 2990WX did the same
> thing.  I guess that patch never landed?  102°C - 49°C is the very
> reasonable 53°C.
>
> Yeah, sigh, it never landed:  https://reviews.freebsd.org/D16855
>
> Ok I'll go ahead and commit that too.
>
> Thanks,
> Conrad
> On Tue, Nov 13, 2018 at 8:38 PM Conrad Meyer  wrote:
> >
> > On Tue, Nov 13, 2018 at 8:29 PM Rebecca Cran  wrote:
> > >
> > > On Tuesday, 13 November 2018 21:17:59 MST Conrad Meyer wrote:
> > >
> > > > Maybe it should be -54 instead of +54?  183-(54*2) is the somewhat
> > > > plausible 75?C (still pretty warm even for load).  How good is your
> > > > cooling solution?
> > >
> > > D'oh, of course it's -54 instead of +54 (For some reason I presumed a 
> > > positive
> > > offset would be *subtracted*)!   I have an all-in-one liquid thermaltake
> > > cooler installed, and under Windows it reports reaching 67C when running 
> > > flat
> > > out, which doesn't seem bad.
> >
> > Yeah, 67C seems totally great at load.
> >
> > > > (The references I can find with a quick search suggest TR 29xx should
> > > > also be -27? rather than -54?C, but they may be mistaken.  183-54-27
> > > > is still 102?C ? extremely hot!)
> > >
> > > That's why I thought 54 was more likely! My 2990WX has 4 units for 32 
> > > cores
> > > instead of 2 units and 16 cores for other models, so I guessed that 
> > > perhaps I
> > > should double the 27 value other people had said should be used.
> >
> > Hm, the Linux folks still use -27 for the 2990WX as well as all of the
> > other threadripper models.  I'm not sure what's right.  I wish I had
> > access to the Ryzen 2 register docs, but I don't.
> >
> > Best,
> > Conrad
___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Rebecca Cran]

On Tuesday, 13 November 2018 21:41:58 MST Conrad Meyer wrote:
> You know what, I wonder if you're running into the CUR_TEMP_RANGE_SEL?
>  I.e., sometimes the CPU chooses to report on a range from 0-225C and
> sometimes -49C-206C.  I think someone else's 2990WX did the same
> thing.  I guess that patch never landed?  102°C - 49°C is the very
> reasonable 53°C.
> 
> Yeah, sigh, it never landed:  https://reviews.freebsd.org/D16855

Thanks, that's it: setting the sensor_offset sysctls to -76 results in FreeBSD 
reporting 51.1C while the readout on the motherboard shows 51C :)

I'll fetch and build r340426 tomorrow.

-- 
Rebecca


___
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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

Perfect!  Sounds like we are on the right track, at least.

Best,
Conrad
On Tue, Nov 13, 2018 at 8:55 PM Rebecca Cran  wrote:
>
> On Tuesday, 13 November 2018 21:41:58 MST Conrad Meyer wrote:
> > You know what, I wonder if you're running into the CUR_TEMP_RANGE_SEL?
> >  I.e., sometimes the CPU chooses to report on a range from 0-225C and
> > sometimes -49C-206C.  I think someone else's 2990WX did the same
> > thing.  I guess that patch never landed?  102°C - 49°C is the very
> > reasonable 53°C.
> >
> > Yeah, sigh, it never landed:  https://reviews.freebsd.org/D16855
>
> Thanks, that's it: setting the sensor_offset sysctls to -76 results in FreeBSD
> reporting 51.1C while the readout on the motherboard shows 51C :)
>
> I'll fetch and build r340426 tomorrow.
>
> --
> Rebecca
>
>
___
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"

recent 13.0-CURRENT double panic near start of poudriere run

[Don Lewis]

I've been doing a bunch of packing building today on my Ryzen box and
just got this kernel panic near the start of a poudriere run:

13.0-CURRENT FreeBSD 13.0-CURRENT r340358 GENERIC  amd64

[00:00:08] Processing PRIORITY_BOOST
[00:00:08] Balancing pool
[00:00:08] Recording filesystem state for prepkg... done
[00:00:09] Building 315 packages using 16 builders
[00:00:09] Starting/Cloning builders
[ system paniced and dropped into ddb ]

# /usr/local/bin/kgdb /boot/kernel/kernel /var/crash/vmcore.3
GNU gdb (GDB) 8.2 [GDB v8.2 for FreeBSD]
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd13.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from 
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.

Unread portion of the kernel message buffer:
timeout stopping cpus
panic: mutex sched lock 2 recursed at /usr/src/sys/kern/kern_synch.c:390
cpuid = 2
time = 1542176879
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00779645f0
vpanic() at vpanic+0x1a3/frame 0xfe0077964650
panic() at panic+0x43/frame 0xfe00779646b0
__mtx_assert() at __mtx_assert+0x69/frame 0xfe00779646c0
mi_switch() at mi_switch+0x42/frame 0xfe00779646f0
critical_exit_preempt() at critical_exit_preempt+0x66/frame 0xfe0077964710
lapic_handle_timer() at lapic_handle_timer+0xe4/frame 0xfe0077964750
Xtimerint() at Xtimerint+0xae/frame 0xfe0077964750
--- interrupt, rip = 0x80bf7860, rsp = 0xfe0077964820, rbp = 
0xfe0077964840 ---
generic_stop_cpus() at generic_stop_cpus+0x170/frame 0xfe0077964840
stop_cpus_hard() at stop_cpus_hard+0x22/frame 0xfe0077964870
vpanic() at vpanic+0xb0/frame 0xfe00779648f0
panic() at panic+0x43/frame 0xfe0077964950
mi_switch() at mi_switch+0x1ff/frame 0xfe0077964980
critical_exit_preempt() at critical_exit_preempt+0x66/frame 0xfe00779649a0
sched_idletd() at sched_idletd+0x517/frame 0xfe0077964a70
fork_exit() at fork_exit+0x84/frame 0xfe0077964ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe0077964ab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic

__curthread () at ./machine/pcpu.h:230
230 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" 
(OFFSETOF_CURTHREAD));

(kgdb) bt
#0  __curthread () at ./machine/pcpu.h:230
#1  doadump (textdump=-2118704160) at /usr/src/sys/kern/kern_shutdown.c:371
#2  0x804659bc in db_fncall_generic (addr=, 
rv=, nargs=, args=)
at /usr/src/sys/ddb/db_command.c:609
#3  db_fncall (dummy1=, dummy2=, 
dummy3=, dummy4=)
at /usr/src/sys/ddb/db_command.c:657
#4  0x804654f9 in db_command (last_cmdp=, 
cmd_table=, dopager=)
at /usr/src/sys/ddb/db_command.c:481
#5  0x80465274 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:534
#6  0x8046848f in db_trap (type=, code=)
at /usr/src/sys/ddb/db_main.c:252
#7  0x80be7925 in kdb_trap (type=3, code=0, tf=)
at /usr/src/sys/kern/subr_kdb.c:692
#8  0x81074946 in trap (frame=0xfe0077964520)
at /usr/src/sys/amd64/amd64/trap.c:619
#9  
#10 kdb_enter (why=0x813065f5 "panic", msg=)
at /usr/src/sys/kern/subr_kdb.c:479
#11 0x80b9f1f0 in vpanic (fmt=, ap=0xfe0077964690)
--Type  for more, q to quit, c to continue without paging--c
at /usr/src/sys/kern/kern_shutdown.c:866
#12 0x80b9ef93 in panic (fmt=0x81e951d8  
"\304\271,\201\377\377\377\377") at /usr/src/sys/kern/kern_shutdown.c:804
#13 0x80b7ea79 in __mtx_assert (c=, what=, file=0xfe00779644e0 "", line=128) at 
/usr/src/sys/kern/kern_mutex.c:1064
#14 0x80baa6d2 in mi_switch (flags=1544, newtd=0x0) at 
/usr/src/sys/kern/kern_synch.c:390
#15 0x80ba7726 in critical_exit_preempt () at 
/usr/src/sys/kern/kern_switch.c:243
#16 0x811ea434 in critical_exit () at /usr/src/sys/sys/systm.h:266
#17 lapic_handle_timer (frame=0xfe0077964760) at 
/usr/src/sys/x86/x86/local_apic.c:1335
#18 
#19 ia32_pause () at ./machine/cpufunc.h:348
#20 generic_stop_cpus (map=..., type=255) at /usr/src/sys/kern/subr_smp.c:280
#21 0x80bf78f2 in stop_cpus_hard (map=...) at 
/usr/src/sys/kern/subr_smp.c:308
#22 0x80b9f0e0 in vpanic (fmt=0x81210702 "mi_switch: switch in 
a critical section", ap=0xfe0077964930) at 
/usr/src/sys/kern/kern_shutdown.c:828
#23 0xfff