Quick call for info from Bhyve users

[Ravi Pokala]

Hi folks,

Could someone with a handy amd64 Bhyve VM run

kenv | grep smbios

in the VM and shoot me the results? I don't have such a system readily available at the moment, but could really use the info.

Thanks,

Ravi (rpokala@ ; wearing my Vdura (formerly known as Panasas) hat)






--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[void]

Hello,

On Mon, Nov 11, 2024 at 07:45:04PM -0600, Ravi Pokala wrote:
>Hi folks,
>
>Could someone with a handy amd64 Bhyve VM run
>
> kenv | grep smbios
>
>in the VM and shoot me the results? I don't have such a system readily available at the moment, but could really use the info.

% kenv | grep smbios
smbios.bios.vendor="BHYVE"

(14.1-RELEASE-p5 GENERIC amd64 1401000 1401000)
--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Aryeh Friedman]

On Mon, Nov 11, 2024 at 8:45 PM Ravi Pokala <***@freebsd.org> wrote:
>
> Hi folks,
>
> Could someone with a handy amd64 Bhyve VM run
>
> kenv | grep smbios
>
> in the VM and shoot me the results? I don't have such a system readily available at the moment, but could really use the info.
>
> Thanks,

For guest:

***@sarek2048% kenv | grep smbios
hint.smbios.0.mem="0xbfbcb000"
smbios.bios.reldate="03/14/2014"
smbios.bios.revision="0.0"
smbios.bios.vendor="BHYVE"
smbios.bios.version="1.00"
smbios.chassis.maker=" "
smbios.chassis.serial="None"
smbios.chassis.tag="None"
smbios.chassis.type="Unknown"
smbios.chassis.version="1.0"
smbios.memory.enabled="67106816"
smbios.socket.enabled="1"
smbios.socket.populated="1"
smbios.system.family=" "
smbios.system.maker=" "
smbios.system.product="BHYVE"
smbios.system.serial="None"
smbios.system.sku="None"
smbios.system.uuid="80574068-2cc6-6d34-853b-e8ade09ca5f6"
smbios.system.version="1.0"
smbios.version="2.8"

And the host:

smbios.bios.reldate="08/11/2022"
smbios.bios.vendor="American Megatrends International, LLC."
smbios.bios.version="P.20"
smbios.chassis.maker="Micro-Star International Co., Ltd."
smbios.chassis.serial="To be filled by O.E.M."
smbios.chassis.tag="To be filled by O.E.M."
smbios.chassis.type="Desktop"
smbios.chassis.version="5.0"
smbios.memory.enabled="33554432"
smbios.planar.location="To be filled by O.E.M."
smbios.planar.maker="Micro-Star International Co., Ltd."
smbios.planar.product="B550 GAMING GEN3 (MS-7B86)"
smbios.planar.serial="07B8651_N11E812185"
smbios.planar.tag="To be filled by O.E.M."
smbios.planar.version="5.0"
smbios.socket.enabled="1"
smbios.socket.populated="1"
smbios.system.family="To be filled by O.E.M."
smbios.system.maker="Micro-Star International Co., Ltd."
smbios.system.product="MS-7B86"
smbios.system.serial="To be filled by O.E.M."
smbios.system.sku="To be filled by O.E.M."
smbios.system.uuid="86ac8a04-ab86-5911-a547-047c167e3610"
smbios.system.version="5.0"
smbios.version="2.8"



--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[void]

On Tue, Nov 12, 2024 at 06:38:49AM -0500, Aryeh Friedman wrote:
>For guest:
>
>***@sarek2048% kenv | grep smbios
>hint.smbios.0.mem="0xbfbcb000"
>smbios.bios.reldate="03/14/2014"
>smbios.bios.revision="0.0"
>smbios.bios.vendor="BHYVE"
>smbios.bios.version="1.00"
>smbios.chassis.maker=" "
>smbios.chassis.serial="None"
>smbios.chassis.tag="None"
>smbios.chassis.type="Unknown"
>smbios.chassis.version="1.0"
>smbios.memory.enabled="67106816"
>smbios.socket.enabled="1"
>smbios.socket.populated="1"
>smbios.system.family=" "
>smbios.system.maker=" "
>smbios.system.product="BHYVE"
>smbios.system.serial="None"
>smbios.system.sku="None"
>smbios.system.uuid="80574068-2cc6-6d34-853b-e8ade09ca5f6"
>smbios.system.version="1.0"
>smbios.version="2.8"

Huh. This vm shows none of that, apart from smbios.bios.vendor.
How are you launching the vm? In this instance, I'm using the
supplied vmrun.sh.

On this vm, there's this:

% doas sysctl -a | grep smbios
Password:

smbios0: <System Management BIOS> at iomem 0xf1000-0xf101e
smbios0: Version: 2.6, BCD Revision: 2.6
device smbios
dev.smbios.0.%parent: nexus0
dev.smbios.0.%pnpinfo:
dev.smbios.0.%location:
dev.smbios.0.%driver: smbios
dev.smbios.0.%desc: System Management BIOS
dev.smbios.%parent:
--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ravi Pokala]

Many thanks to all the people who replied back to me so quickly!

I got the information I needed.

Thanks again!

-Ravi (rpokala@ ; wearing my Vdura (formerly known as Panasas) hat)

-----Original Message-----
From: Aryeh Friedman <***@gmail.com <mailto:***@gmail.com>>
Date: Tuesday, November 12, 2024 at 05:38
To: Ravi Pokala <***@freebsd.org <mailto:***@freebsd.org>>
Cc: "freebsd-***@freebsd.org <mailto:freebsd-***@freebsd.org>" <freebsd-***@freebsd.org <mailto:freebsd-***@freebsd.org>>
Subject: Re: Quick call for info from Bhyve users


On Mon, Nov 11, 2024 at 8:45 PM Ravi Pokala <***@freebsd.org <mailto:***@freebsd.org>> wrote:
>
> Hi folks,
>
> Could someone with a handy amd64 Bhyve VM run
>
> kenv | grep smbios
>
> in the VM and shoot me the results? I don't have such a system readily available at the moment, but could really use the info.
>
> Thanks,


For guest:


***@sarek2048% kenv | grep smbios
hint.smbios.0.mem="0xbfbcb000"
smbios.bios.reldate="03/14/2014"
smbios.bios.revision="0.0"
smbios.bios.vendor="BHYVE"
smbios.bios.version="1.00"
smbios.chassis.maker=" "
smbios.chassis.serial="None"
smbios.chassis.tag="None"
smbios.chassis.type="Unknown"
smbios.chassis.version="1.0"
smbios.memory.enabled="67106816"
smbios.socket.enabled="1"
smbios.socket.populated="1"
smbios.system.family=" "
smbios.system.maker=" "
smbios.system.product="BHYVE"
smbios.system.serial="None"
smbios.system.sku="None"
smbios.system.uuid="80574068-2cc6-6d34-853b-e8ade09ca5f6"
smbios.system.version="1.0"
smbios.version="2.8"


And the host:


smbios.bios.reldate="08/11/2022"
smbios.bios.vendor="American Megatrends International, LLC."
smbios.bios.version="P.20"
smbios.chassis.maker="Micro-Star International Co., Ltd."
smbios.chassis.serial="To be filled by O.E.M."
smbios.chassis.tag="To be filled by O.E.M."
smbios.chassis.type="Desktop"
smbios.chassis.version="5.0"
smbios.memory.enabled="33554432"
smbios.planar.location="To be filled by O.E.M."
smbios.planar.maker="Micro-Star International Co., Ltd."
smbios.planar.product="B550 GAMING GEN3 (MS-7B86)"
smbios.planar.serial="07B8651_N11E812185"
smbios.planar.tag="To be filled by O.E.M."
smbios.planar.version="5.0"
smbios.socket.enabled="1"
smbios.socket.populated="1"
smbios.system.family="To be filled by O.E.M."
smbios.system.maker="Micro-Star International Co., Ltd."
smbios.system.product="MS-7B86"
smbios.system.serial="To be filled by O.E.M."
smbios.system.sku="To be filled by O.E.M."
smbios.system.uuid="86ac8a04-ab86-5911-a547-047c167e3610"
smbios.system.version="5.0"
smbios.version="2.8"






--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org <http://www.PetiteCloud.org>






--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Tomek CEDRO]

On Wed, Nov 13, 2024 at 9:30 PM George Mitchell <george+***@m5p.com> wrote:
> On 11/12/24 17:46, George Mitchell wrote:
> > Has anyone ever used the MCP2221 chip from Microchip Technology (or any
> > device incorporating it) on FreeBSD? If so, does it attach as both a
> > serial port (cuaUn) AND human interface (uhidn), or just one? Does it
> > work well? Thanks for any information you can give me. -- George
>
> Does FreeBSD have the concept of one hardware device attaching as two
> device nodes? -- George

Hey there George :-)

Yes USB device may expose several interfaces and each one of them may
use different kernel module / subsystem, all over single USB cable,
that works well on FreeBSD. For instance Debug Probes (i.e. DAPLink or
STLink) offer Serial Port for console access, JTAG/SWD/CMSIS HID
interface for debug, and UMS (mass storage) emulation for
drag-and-drop bin file for firmware flashing :-)

I cannot tell if MCP2221 works well because I did not play with that
chip you have to verify in practice sorry.. but it seems something
like FT2232 or CH3421 right? I can see 3 options here depending on
what you need :-)

1. The serial port emulation uses CDC standard, the same with anything
that goes over HID, UMS, and others that are supported here. If this
is a generic implementation it should work out of the box.. the only
thing here that _may_ need an update is the VID:PID pair for a new
chip identification numbers to be added to a specific kernel driver so
it attaches on device connect (i.e. CDC so /dev/cuaU* is showed up).

2. If this is some sort of custom implementation (like FT2232) then
additional driver would be necessary to translate between device
internal registers to something that i.e. CDC can talk with. This is
the case when you want to have native OS driver because of reasons.

3. FreeBSD provides native LibUSB interface that can be used by any
application that already can talk to the chip directly over LibUSB
(i.e. PyMCP2221A [1]). No system drivers are necessary in that case.
For example if the chip is not supported at all here by the system but
you have application that can talk to the chip on its own over libusb
all should work fine :-)

https://github.com/nonNoise/PyMCP2221A

There are standard tools on FreeBSD like usbconfig that allows you to
work with USB subsystem and devices (i.e. view usb device descriptors,
reset, configure interfaces, etc), or devd that allows you to tell
what system should do on device attach/detach events. USB stack is
rock solid :-)

https://man.freebsd.org/cgi/man.cgi?usbconfig

I hope that helps a bit :-)
Tomek

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Tomek CEDRO]

On Wed, Nov 13, 2024 at 11:45 PM George Mitchell <george+***@m5p.com> wrote:
> (..)
> > I cannot tell if MCP2221 works well because I did not play with that
> > chip you have to verify in practice sorry.. but it seems something
> > like FT2232 or CH3421 right? I can see 3 options here depending on
> > what you need :-)
> > (..)
> > I hope that helps a bit :-)
> > Tomek
>
> It does! Thank you. -- George

Okay I just ordered the MCP2221A Breakout Stemma QT/Qwiic for ~10EUR
it should arrive on Friday/Monday will see what happens ;-)

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[George Mitchell]

On 11/13/24 17:59, Tomek CEDRO wrote:
> On Wed, Nov 13, 2024 at 11:45 PM George Mitchell <george+***@m5p.com> wrote:
>> (..)
>>> I cannot tell if MCP2221 works well because I did not play with that
>>> chip you have to verify in practice sorry.. but it seems something
>>> like FT2232 or CH3421 right? I can see 3 options here depending on
>>> what you need :-)
>>> (..)
>>> I hope that helps a bit :-)
>>> Tomek
>>
>> It does! Thank you. -- George
>
> Okay I just ordered the MCP2221A Breakout Stemma QT/Qwiic for ~10EUR
> it should arrive on Friday/Monday will see what happens ;-)
>
That just happens to be the board I was hoping to get! -- George

[Tomek CEDRO]

On Thu, Nov 14, 2024 at 12:08 AM George Mitchell <george+***@m5p.com> wrote:
> > Okay I just ordered the MCP2221A Breakout Stemma QT/Qwiic for ~10EUR
> > it should arrive on Friday/Monday will see what happens ;-)
> >
> That just happens to be the board I was hoping to get! -- George

Cool I will let you know how it works :-) I also ordered some ESP32S3
module with LCD and touch for NuttX RTOS + LVGL testing, and rPI-Zero
because I did not have one yet and its cheap and seems powerful enough
not only to run NuttX RTOS but also FreeBSD!! :D

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Bakul Shah]

On Nov 13, 2024, at 3:21 PM, Tomek CEDRO <***@cedro.info> wrote:
>
> rPI-Zero
> because I did not have one yet and its cheap and seems powerful enough
> not only to run NuttX RTOS but also FreeBSD!! :D

piZero models older than Zero 2 W are not 64 bit capable. If it matters.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Tomek CEDRO]

On Thu, Nov 14, 2024 at 12:29 AM Bakul Shah <***@iitbombay.org> wrote:
> On Nov 13, 2024, at 3:21 PM, Tomek CEDRO <***@cedro.info> wrote:
> > rPI-Zero
> > because I did not have one yet and its cheap and seems powerful enough
> > not only to run NuttX RTOS but also FreeBSD!! :D
>
> piZero models older than Zero 2 W are not 64 bit capable. If it matters.

Thanks Bakul!! I just updated my order to rPI02W :-) :-)

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Tomek CEDRO]

On Thu, Nov 14, 2024 at 12:21 AM Tomek CEDRO <***@cedro.info> wrote:
> On Thu, Nov 14, 2024 at 12:08 AM George Mitchell <george+***@m5p.com> wrote:
> > > Okay I just ordered the MCP2221A Breakout Stemma QT/Qwiic for ~10EUR
> > > it should arrive on Friday/Monday will see what happens ;-)
> > That just happens to be the board I was hoping to get! -- George
> Cool I will let you know how it works :-)

This MCP2221A works like a charm out of the box on FreeBSD 13.3 :-)

Nov 16 02:08:30 octagon kernel: ugen0.6: <Microchip Technology Inc.
MCP2221 USB-I2C/UART Combo> at usbus0
Nov 16 02:08:30 octagon kernel: umodem0 on uhub21
Nov 16 02:08:30 octagon kernel: umodem0: <Microchip Technology Inc.
MCP2221 USB-I2C/UART Combo, class 239/2, rev 2.00/1.00, addr 5> on
usbus0
Nov 16 02:08:30 octagon kernel: umodem0: data interface 1, has no CM
over data, has no break
Nov 16 02:08:30 octagon kernel: usbhid5 on uhub21
Nov 16 02:08:30 octagon kernel: usbhid5: <Microchip Technology Inc.
MCP2221 USB-I2C/UART Combo, class 239/2, rev 2.00/1.00, addr 5> on
usbus0
Nov 16 02:08:30 octagon kernel: hidbus5: <HID bus> on usbhid5

Then /dev/cuaU0 shows up and I can connect to some board over UART:

nsh> uname -a
NuttX 12.7.0 5d8cdeaea8-dirty Nov 16 2024 02:02:28 arm nucleo-f4x1re

I used minicom to change baud and it seems to work. Note this chip
does not have control lines so you probably need to use GPIO to reset
/ select boot if necessary.

Regarding the additional stuff it seems to work in Python over hid but
I did not play any further (after cable disconnect I got errors on
commands so there is some communication).

(venv3.11embedded) python
Python 3.11.10 (main, Sep 14 2024, 01:19:37) [Clang 17.0.6
(https://github.com/llvm/llvm-project.git llvmorg-17.0.6-0-g600970 on
freebsd13
Type "help", "copyright", "credits" or "license" for more information.
>>> from PyMCP2221A import PyMCP2221A
>>> mcp2221 = PyMCP2221A.PyMCP2221A()
>>> mcp2221.GPIO_Init()
mcp2221.ADC_1_Init() mcp2221.CLKDIV_2
mcp2221.CLKDUTY_25 mcp2221.DAC_2_Init()
mcp2221.GPIO_0_InputMode() mcp2221.GPIO_1_Input()
mcp2221.GPIO_2_DIR mcp2221.GPIO_3_BIT
mcp2221.GPIO_3_OutputMode() mcp2221.I2C_Read(
mcp2221.Read_Flash_Data(
mcp2221.ADC_2_Init() mcp2221.CLKDIV_32
mcp2221.CLKDUTY_50 mcp2221.DAC_Datawrite(
mcp2221.GPIO_0_MODE mcp2221.GPIO_1_InputMode()
mcp2221.GPIO_2_Input() mcp2221.GPIO_3_DIR
mcp2221.GPIO_Init() mcp2221.I2C_Read_Repeated(
mcp2221.Reset()
mcp2221.ADC_3_Init() mcp2221.CLKDIV_4
mcp2221.CLKDUTY_75 mcp2221.DeviceDriverInfo()
mcp2221.GPIO_0_Output( mcp2221.GPIO_1_MODE
mcp2221.GPIO_2_InputMode() mcp2221.GPIO_3_Input()
mcp2221.GPIO_Read() mcp2221.I2C_State_Check()
mcp2221.Write_Flash_Data(
mcp2221.ADC_DataRead() mcp2221.CLKDIV_64
mcp2221.ClockOut( mcp2221.GPIO_0_BIT
mcp2221.GPIO_0_OutputMode() mcp2221.GPIO_1_Output(
mcp2221.GPIO_2_MODE mcp2221.GPIO_3_InputMode()
mcp2221.GPIO_Write() mcp2221.I2C_Write(
mcp2221.mcp2221a
mcp2221.CLKDIV_128 mcp2221.CLKDIV_8
mcp2221.Command_Structure( mcp2221.GPIO_0_DIR
mcp2221.GPIO_1_BIT mcp2221.GPIO_1_OutputMode()
mcp2221.GPIO_2_Output( mcp2221.GPIO_3_MODE
mcp2221.I2C_Cancel() mcp2221.I2C_Write_No_Stop(
mcp2221.CLKDIV_16 mcp2221.CLKDUTY_0
mcp2221.DAC_1_Init() mcp2221.GPIO_0_Input()
mcp2221.GPIO_1_DIR mcp2221.GPIO_2_BIT
mcp2221.GPIO_2_OutputMode() mcp2221.GPIO_3_Output(
mcp2221.I2C_Init( mcp2221.I2C_Write_Repeated(

Regarding the rPI Zero 2W I dd'ed the 14.1 SD image for RPI and got
the rainbow box on hdmi but some updates are needed in the firmware
files on first partition, I quickly updated to git master but that did
not help, and I not rally have time now to play, but it was fun to try
:-)

Have fun George :-)

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[George Mitchell]

On 11/14/24 02:38, Andriy Gapon wrote:
> On 13/11/2024 22:29, George Mitchell wrote:
>> On 11/12/24 17:46, George Mitchell wrote:
>>> Has anyone ever used the MCP2221 chip from Microchip Technology (or any
>>> device incorporating it) on FreeBSD?  If so, does it attach as both a
>>> serial port (cuaUn) AND human interface (uhidn), or just one?  Does it
>>> work well?  Thanks for any information you can give me.       -- George
>>
>> Does FreeBSD have the concept of one hardware device attaching as two
>> device nodes?                                                  -- George
>
> Take a look at cp2112 driver, for instance.
>
Thanks, Andriy! -- George

[Alan Somers]

On Fri, Nov 22, 2024 at 7:07 AM Mark Johnston <***@freebsd.org> wrote:
>
> On Thu, Nov 21, 2024 at 04:06:53PM -0700, Alan Somers wrote:
> > Would it be possible to make dtrace with with KMSAN? It would
> > certainly make my life easier. As it is, every time I try to kldload
> > traceall, whether from the command line or in the loader, my VM
> > infinite loops printing alerts like this:
> >
> > MSan: Uninitialized stack memory from isize64+0x2e
> > #0 0xffffffff833d8f10 at __msan_warning+0x140
> > #1 0xffffffff86ec9c03 at dtrace_disp_opnd+0xd3
> > #2 0xffffffff86ebe552 at dtrace_disx86+0xc602
> > #3 0xffffffff86eca98e at dtrace_instr_size+0xee
> > #4 0xffffffff86d5ec27 at fbt_provide_module_function+0x957
> > #5 0xffffffff83303eff at link_elf_each_function_nameval+0x56f
> > #6 0xffffffff86d56cb3 at fbt_provide_module+0x423
> > #7 0xffffffff86d56871 at fbt_linker_file_cb+0x41
> > #8 0xffffffff830d9f5c at linker_file_foreach+0xdc
> > #9 0xffffffff830d63dd at linker_load_module+0x413d
> > #10 0xffffffff830e6116 at linker_load_dependencies+0x1136
> > #11 0xffffffff853b70b8 at link_elf_load_file+0x65c8
> > #12 0xffffffff830d542e at linker_load_module+0x318e
> > #13 0xffffffff830e0611 at kern_kldload+0x5d1
> > #14 0xffffffff830e0d74 at sys_kldload+0x1a4
> > #15 0xffffffff84fe56f6 at amd64_syscall+0x706
> > #16 0xffffffff84f0ef4b at fast_syscall_common+0xf8
> >
>
> Here you go:
>
> https://cgit.freebsd.org/src/commit/?id=418d8f0dc269b314bba51de63869b20da1d9a76e
> https://cgit.freebsd.org/src/commit/?id=cc3da1955c16df5eb0019e0fef810696b035b7cf
>
> This one might also be important if your test system is low on RAM,
> since the KMSAN shadow map gobbles up quite a lot of memory:
>
> https://cgit.freebsd.org/src/commit/?id=5d12db2dafece9f6a0453c4a45c4abed6b1e15ec
>
> I haven't yet tried running through the full test suite, but this was
> enough to load dtracell (quite slow under KMSAN) and run some simple
> scripts.

Wow, thanks! I'll try it out later today.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[alan somers]

On Fri, Nov 22, 2024 at 7:47 AM Alan Somers <***@freebsd.org> wrote:
>
> On Fri, Nov 22, 2024 at 7:07 AM Mark Johnston <***@freebsd.org> wrote:
> >
> > On Thu, Nov 21, 2024 at 04:06:53PM -0700, Alan Somers wrote:
> > > Would it be possible to make dtrace with with KMSAN? It would
> > > certainly make my life easier. As it is, every time I try to kldload
> > > traceall, whether from the command line or in the loader, my VM
> > > infinite loops printing alerts like this:
> > >
> > > MSan: Uninitialized stack memory from isize64+0x2e
> > > #0 0xffffffff833d8f10 at __msan_warning+0x140
> > > #1 0xffffffff86ec9c03 at dtrace_disp_opnd+0xd3
> > > #2 0xffffffff86ebe552 at dtrace_disx86+0xc602
> > > #3 0xffffffff86eca98e at dtrace_instr_size+0xee
> > > #4 0xffffffff86d5ec27 at fbt_provide_module_function+0x957
> > > #5 0xffffffff83303eff at link_elf_each_function_nameval+0x56f
> > > #6 0xffffffff86d56cb3 at fbt_provide_module+0x423
> > > #7 0xffffffff86d56871 at fbt_linker_file_cb+0x41
> > > #8 0xffffffff830d9f5c at linker_file_foreach+0xdc
> > > #9 0xffffffff830d63dd at linker_load_module+0x413d
> > > #10 0xffffffff830e6116 at linker_load_dependencies+0x1136
> > > #11 0xffffffff853b70b8 at link_elf_load_file+0x65c8
> > > #12 0xffffffff830d542e at linker_load_module+0x318e
> > > #13 0xffffffff830e0611 at kern_kldload+0x5d1
> > > #14 0xffffffff830e0d74 at sys_kldload+0x1a4
> > > #15 0xffffffff84fe56f6 at amd64_syscall+0x706
> > > #16 0xffffffff84f0ef4b at fast_syscall_common+0xf8
> > >
> >
> > Here you go:
> >
> > https://cgit.freebsd.org/src/commit/?id=418d8f0dc269b314bba51de63869b20da1d9a76e
> > https://cgit.freebsd.org/src/commit/?id=cc3da1955c16df5eb0019e0fef810696b035b7cf
> >
> > This one might also be important if your test system is low on RAM,
> > since the KMSAN shadow map gobbles up quite a lot of memory:
> >
> > https://cgit.freebsd.org/src/commit/?id=5d12db2dafece9f6a0453c4a45c4abed6b1e15ec
> >
> > I haven't yet tried running through the full test suite, but this was
> > enough to load dtracell (quite slow under KMSAN) and run some simple
> > scripts.
>
> Wow, thanks! I'll try it out later today.

It works now. I can load the module and do some probes. Other
probes, though, still trigger warnings. For instance,
'fbt:zfs:zio_data_buf_alloc:entry {@z[stack()] = count();}' triggers
warnings like this:

MSan: Uninitialized stack memory in copyout():arg1, offset 24/368,
addr 0xfffffe00b68ae018, from w_stillcold+0x28
#0 0xffffffff8340009c at kmsan_report_hook+0x15c
#1 0xffffffff833dbc61 at kmsan_copyout+0x1f1
#2 0xffffffff87e800f0 at dtrace_ioctl+0x4420
#3 0xffffffff8297795f at devfs_ioctl+0x3ef
#4 0xffffffff8547c277 at VOP_IOCTL_APV+0x107
#5 0xffffffff8381f974 at vn_ioctl+0x7a4
#6 0xffffffff8297a0f6 at devfs_ioctl_f+0x186
#7 0xffffffff834f3c2b at kern_ioctl+0xc5b
#8 0xffffffff834f2dc0 at sys_ioctl+0x580
#9 0xffffffff84fe7836 at amd64_syscall+0x706
#10 0xffffffff84f1128b at fast_syscall_common+0xf8


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de