syslogd no longer listens (or sends) on a network socket

[Michael Butler]

It appears that SVN r309925 and onward no longer opens a network socket 
unless the command-line explicitly contains "-b :syslog" :-(


This also stops one syslog daemon forwarding to another (which is why I 
noticed).


Was this an intentional behaviour change?

Michael
___
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: best approximation of getcpu() ?

[Alan Somers]

On Thu, Dec 15, 2016 at 7:17 PM, Luigi Rizzo  wrote:
> TL;DR; is there any way a userspace thread in FreeBSD can tell
> on which CPU it is (was) running ? I know the thread can migrate
> at any time but as long as the event is rare I can live with
> the occasionally wrong information.
> Linux has getcpu(2) which is exposed by glibc as sched_getcpu(3),
> but the linuxulator in FreeBSD only has a dummy (uniplemented)
> function for that syscall.
>
> FULL DESCRIPTION
> It is common practice, when building scalable systems, to use per-cpu
> resources that can be accessed without contention by just protecting
> them with a CLI; STI; pair. Multiqueue NICs typically do this to
> build a lock-free transmit path. In [1] we show an in-kernel
> scheduler that maps a large number of clients to a (much smaller)
> number of lock-free mailboxes, one per core.
>
> In the kernel we can do CLI and STI and access curcpu.
> In userspace a suitably privileged process can indeed open /dev/io
> to acquire the right to use CLI and STI, though I am not sure
> wether curcpu is available in some way.
>
> Of course running userspace code with interrupts disabled is risky,
> but we can use the per-cpu trick with a small tweak, namely,
> protect each resouce with a lock. If the thread does not migrate
> imediately after getcpu(), we will access the lock (and the resource)
> almost always from the same cpu hence very efficiently.
> Occasional migration may cause contention but should not
> alter too much the good performance of this scheme.
>
> So, any idea before I add a syscall/ioctl (or extend one)
> to export this information ?
>
> thanks
> luigi
>
>
> [1] http://info.iet.unipi.it/~luigi/papers/20160921-pspat.pdf

What about pthread_setaffinity(3) and friends?  You can use it to pin
a thread to a single CPU, and know that it will never migrate.

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

best approximation of getcpu() ?

[Luigi Rizzo]

TL;DR; is there any way a userspace thread in FreeBSD can tell
on which CPU it is (was) running ? I know the thread can migrate
at any time but as long as the event is rare I can live with
the occasionally wrong information.
Linux has getcpu(2) which is exposed by glibc as sched_getcpu(3),
but the linuxulator in FreeBSD only has a dummy (uniplemented)
function for that syscall.

FULL DESCRIPTION
It is common practice, when building scalable systems, to use per-cpu
resources that can be accessed without contention by just protecting
them with a CLI; STI; pair. Multiqueue NICs typically do this to
build a lock-free transmit path. In [1] we show an in-kernel
scheduler that maps a large number of clients to a (much smaller)
number of lock-free mailboxes, one per core.

In the kernel we can do CLI and STI and access curcpu.
In userspace a suitably privileged process can indeed open /dev/io
to acquire the right to use CLI and STI, though I am not sure
wether curcpu is available in some way.

Of course running userspace code with interrupts disabled is risky,
but we can use the per-cpu trick with a small tweak, namely,
protect each resouce with a lock. If the thread does not migrate
imediately after getcpu(), we will access the lock (and the resource)
almost always from the same cpu hence very efficiently.
Occasional migration may cause contention but should not
alter too much the good performance of this scheme.

So, any idea before I add a syscall/ioctl (or extend one)
to export this information ?

thanks
luigi


[1] http://info.iet.unipi.it/~luigi/papers/20160921-pspat.pdf
___
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"

Questions about FreeBSD support for NVDIMM

[Qi Zhang]

Dear All,
Does anybody know NVDIMM support status and plan in current FreeBSD?  I noticed 
this message "Have "Traditional" NVDIMM support (rpokala@)" on 
https://wiki.freebsd.org/VendorDevSummit/201611/HaveNeedWant. If anyone knows 
about the details, please share with me and I will appreciate that.

Thanks
Best Regards
- Qi (Keira)
GOSV | 18F, Raycom, Beijing | +86-10-599 34604




___
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: Enabling NUMA in BIOS stop booting FreeBSD

[Adrian Chadd]

heh, an updated BIOS that solves the problem will solve the problem. :)

I think you have enough information to provide to supermicro. Ie,
"SMAP says X, when physical memory pages at addresses X are accessed,
they don't behave like memory, maybe something is wrong".

All I can think of is some hack to add a blacklist for that region so
you can boot the unit. But it makes me wonder what else is going on.


-adrian
___
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: Enabling NUMA in BIOS stop booting FreeBSD

[Slawa Olhovchenkov]

On Thu, Dec 15, 2016 at 03:56:56PM +0200, Konstantin Belousov wrote:

> > > Possibly, the dmesg of the boot (with late_console=0) with this and only
> > > this patch applied against stock HEAD.  This might be long.
> > 
> > Do you need all (262144?) lines?
> > 
> > Testing system
> > memorypb
> >  0x204000
> > pb 0x2040001000
> > pb 0x2040002000
> > pb 0x2040003000
> > pb 0x2040004000
> > pb 0x2040005000
> > pb 0x2040006000
> > [...]
> > pb 0x207000
> > 
> > > diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
> > > index 682307f5fe4..072c8d76acf 100644
> > > --- a/sys/amd64/amd64/machdep.c
> > > +++ b/sys/amd64/amd64/machdep.c
> > > @@ -1400,6 +1400,7 @@ getmemsize(caddr_t kmdp, u_int64_t first)
> > >*/
> > >   *(int *)ptr = tmp;
> > >  
> > > +if (page_bad) printf("pb 0x%lx\n", pa);
> > >  skip_memtest:
> > >   /*
> > >* Adjust array of valid/good pages.
> > 
> > PS: memtest86 hung at test 128-130G (server have 128G installed).
> Well, the physical memory is 128G, but it is not mapped contiguously into
> the address space accessible to the processors.  E.g. in the SMAPs you
> posted above, there are several holes (type 2) used for PCIe config
> window, PCI BARs, APICs, and other i/o register pages.  Intel chipsets
> allow to remap the RAM hidden by the io pages, which is probably not
> done correctly by BIOS.
> 
> The SMAP clearly reports segment 0x1-0x208000 as populated
> by RAM, this is 4G-130G.  Very primitive memory test in kernel does
> not like all pages starting at 129G.  Possibly important detail is that
> kernel memory test only touches first 4 bytes on each page.  So if BIOS
> erronously mapped any io registers into that range, memory test might
> luckily avoid touching anything critical, but still noting that the
> page does not behave as RAM.
> 
> Update BIOS, and if the issue persists, contact supermicro. This
> interesting detail adds even more evidence that BIOS is problematic.

Updated BIOS don't solve this.
___
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: FreeBSD_HEAD_amd64_gcc - Build #1733 - Still Failing

[Li-Wen Hsu]

On Thu, Dec 15, 2016 at 12:42:00 +0100, Dimitry Andric wrote:
> On 15 Dec 2016, at 12:03, jenkins-ad...@freebsd.org wrote:
> > 
> > FreeBSD_HEAD_amd64_gcc - Build #1733 - Still Failing:
> > 
> > Build information: 
> > https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1733/
> > Full change log: 
> > https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1733/changes
> > Full build log: 
> > https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1733/console
> ...
> > building shared library libprivatedevdctl.so.0
> > /usr/local/bin/x86_64-portbld-freebsd10.1-g++ -isystem 
> > /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include/c++/v1
> >  -std=c++11 -nostdinc++ -isystem 
> > /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include
> >  
> > -L/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib
> >  
> > -B/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib
> >  
> > --sysroot=/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp
> >  -B/usr/local/x86_64-freebsd/bin/  -fstack-protector-strong -shared -Wl,-x 
> > -Wl,--fatal-warnings -Wl,--warn-shared-textrel  -o 
> > libprivatedevdctl.so.0.full -Wl,-soname,libprivatedevdctl.so.0  
> > `NM='/usr/local/x86_64-freebsd/bin/nm' NMFLAGS='' lorder consumer.pico 
> > event.pico event_factory.pico exception.pico guid.pico |  tsort -q`
> > /usr/local/bin/x86_64-freebsd-ld: cannot find -lstdc++
> 
> Dear Jenkins admins, can you please install a more recent version of
> amd64-xtoolchain-gcc on the slave?  This is required to avoid the above
> error about not being able to find libstdc++.

Also from the console log:

+ sudo pkg install -y devel/amd64-xtoolchain-gcc
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Checking integrity... done (0 conflicting)
The most recent version of packages are already installed

The build script install/update the latest devel/amd64-xtoolchain-gcc
package.  I think the problem is we did not upgrade the dependencies.  I
cannot think of a elegant way to upgrade all amd64-xtoolchain-gcc's
dependencies, so I added a line to build script to upgrade everything
before build.

Let see if this works.

Best,
Li-Wen

-- 
Li-Wen Hsu 
https://lwhsu.org


signature.asc
Description: PGP signature

Re: Enabling NUMA in BIOS stop booting FreeBSD

[Konstantin Belousov]

On Thu, Dec 15, 2016 at 04:16:24PM +0300, Slawa Olhovchenkov wrote:
> On Thu, Dec 15, 2016 at 02:33:30PM +0200, Konstantin Belousov wrote:
> 
> > On Thu, Dec 15, 2016 at 01:51:18PM +0300, Slawa Olhovchenkov wrote:
> > > On Wed, Dec 14, 2016 at 09:03:49PM +0200, Konstantin Belousov wrote:
> > > 
> > > > So my opinion did not changed, this sounds like firmware problem.
> > > > I do not see how can I drill into it more.
> > > 
> > > I am don't know how it related. msgbufp mapped different with and w/o
> > > memory test:
> > > 
> > > w/o memory test, hang:
> > > msgbufp=0xf8207ff0 pa_indx=7 phys_avail[pa_indx]=207ff0
> > > 
> > > w/ memory test, boot:
> > > msgbufp=0xf8203ff0 pa_indx=7 phys_avail[pa_indx]=203ff0
> > Interesting.
> > 
> > Can you show me
> > - the output of the smap command from the loader (yes, I know it was already
> >   shown, I want it in the same mail as the data below for convenience);
> 
> OK set hw.memtest.tests=1
> OK smap
> SMAP type=01 base= len=00099c00 attr=01
> SMAP type=02 base=00099c00 len=6400 attr=01
> SMAP type=02 base=000e len=0002 attr=01
> SMAP type=01 base=0010 len=7906b000 attr=01
> SMAP type=02 base=7916b000 len=00936000 attr=01
> SMAP type=04 base=79aa1000 len=00509000 attr=01
> SMAP type=02 base=79faa000 len=02056000 attr=01
> SMAP type=01 base=0001 len=001f8000 attr=01
> SMAP type=02 base=7c00 len=1400 attr=01
> SMAP type=02 base=fed1c000 len=00029000 attr=01
> SMAP type=02 base=ff00 len=0100 attr=01
> 
> > - the output of sysctl machdep.smap after the succesfull boot with the
> >   memtest enabled.
> 
> machdep.smap:
> SMAP type=01, xattr=01, base=, len=00099c00
> SMAP type=02, xattr=01, base=00099c00, len=6400
> SMAP type=02, xattr=01, base=000e, len=0002
> SMAP type=01, xattr=01, base=0010, len=7906b000
> SMAP type=02, xattr=01, base=7916b000, len=00936000
> SMAP type=04, xattr=01, base=79aa1000, len=00509000
> SMAP type=02, xattr=01, base=79faa000, len=02056000
> SMAP type=01, xattr=01, base=0001, len=001f8000
> SMAP type=02, xattr=01, base=7c00, len=1400
> SMAP type=02, xattr=01, base=fed1c000, len=00029000
> SMAP type=02, xattr=01, base=ff00, len=0100
> 
> > Possibly, the dmesg of the boot (with late_console=0) with this and only
> > this patch applied against stock HEAD.  This might be long.
> 
> Do you need all (262144?) lines?
> 
> Testing system
> memorypb
>  0x204000
> pb 0x2040001000
> pb 0x2040002000
> pb 0x2040003000
> pb 0x2040004000
> pb 0x2040005000
> pb 0x2040006000
> [...]
> pb 0x207000
> 
> > diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
> > index 682307f5fe4..072c8d76acf 100644
> > --- a/sys/amd64/amd64/machdep.c
> > +++ b/sys/amd64/amd64/machdep.c
> > @@ -1400,6 +1400,7 @@ getmemsize(caddr_t kmdp, u_int64_t first)
> >  */
> > *(int *)ptr = tmp;
> >  
> > +if (page_bad) printf("pb 0x%lx\n", pa);
> >  skip_memtest:
> > /*
> >  * Adjust array of valid/good pages.
> 
> PS: memtest86 hung at test 128-130G (server have 128G installed).
Well, the physical memory is 128G, but it is not mapped contiguously into
the address space accessible to the processors.  E.g. in the SMAPs you
posted above, there are several holes (type 2) used for PCIe config
window, PCI BARs, APICs, and other i/o register pages.  Intel chipsets
allow to remap the RAM hidden by the io pages, which is probably not
done correctly by BIOS.

The SMAP clearly reports segment 0x1-0x208000 as populated
by RAM, this is 4G-130G.  Very primitive memory test in kernel does
not like all pages starting at 129G.  Possibly important detail is that
kernel memory test only touches first 4 bytes on each page.  So if BIOS
erronously mapped any io registers into that range, memory test might
luckily avoid touching anything critical, but still noting that the
page does not behave as RAM.

Update BIOS, and if the issue persists, contact supermicro. This
interesting detail adds even more evidence that BIOS is problematic.
___
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: Enabling NUMA in BIOS stop booting FreeBSD

[Slawa Olhovchenkov]

On Thu, Dec 15, 2016 at 02:33:30PM +0200, Konstantin Belousov wrote:

> On Thu, Dec 15, 2016 at 01:51:18PM +0300, Slawa Olhovchenkov wrote:
> > On Wed, Dec 14, 2016 at 09:03:49PM +0200, Konstantin Belousov wrote:
> > 
> > > So my opinion did not changed, this sounds like firmware problem.
> > > I do not see how can I drill into it more.
> > 
> > I am don't know how it related. msgbufp mapped different with and w/o
> > memory test:
> > 
> > w/o memory test, hang:
> > msgbufp=0xf8207ff0 pa_indx=7 phys_avail[pa_indx]=207ff0
> > 
> > w/ memory test, boot:
> > msgbufp=0xf8203ff0 pa_indx=7 phys_avail[pa_indx]=203ff0
> Interesting.
> 
> Can you show me
> - the output of the smap command from the loader (yes, I know it was already
>   shown, I want it in the same mail as the data below for convenience);

OK set hw.memtest.tests=1
OK smap
SMAP type=01 base= len=00099c00 attr=01
SMAP type=02 base=00099c00 len=6400 attr=01
SMAP type=02 base=000e len=0002 attr=01
SMAP type=01 base=0010 len=7906b000 attr=01
SMAP type=02 base=7916b000 len=00936000 attr=01
SMAP type=04 base=79aa1000 len=00509000 attr=01
SMAP type=02 base=79faa000 len=02056000 attr=01
SMAP type=01 base=0001 len=001f8000 attr=01
SMAP type=02 base=7c00 len=1400 attr=01
SMAP type=02 base=fed1c000 len=00029000 attr=01
SMAP type=02 base=ff00 len=0100 attr=01

> - the output of sysctl machdep.smap after the succesfull boot with the
>   memtest enabled.

machdep.smap:
SMAP type=01, xattr=01, base=, len=00099c00
SMAP type=02, xattr=01, base=00099c00, len=6400
SMAP type=02, xattr=01, base=000e, len=0002
SMAP type=01, xattr=01, base=0010, len=7906b000
SMAP type=02, xattr=01, base=7916b000, len=00936000
SMAP type=04, xattr=01, base=79aa1000, len=00509000
SMAP type=02, xattr=01, base=79faa000, len=02056000
SMAP type=01, xattr=01, base=0001, len=001f8000
SMAP type=02, xattr=01, base=7c00, len=1400
SMAP type=02, xattr=01, base=fed1c000, len=00029000
SMAP type=02, xattr=01, base=ff00, len=0100

> Possibly, the dmesg of the boot (with late_console=0) with this and only
> this patch applied against stock HEAD.  This might be long.

Do you need all (262144?) lines?

Testing system
memorypb
 0x204000
pb 0x2040001000
pb 0x2040002000
pb 0x2040003000
pb 0x2040004000
pb 0x2040005000
pb 0x2040006000
[...]
pb 0x207000

> diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
> index 682307f5fe4..072c8d76acf 100644
> --- a/sys/amd64/amd64/machdep.c
> +++ b/sys/amd64/amd64/machdep.c
> @@ -1400,6 +1400,7 @@ getmemsize(caddr_t kmdp, u_int64_t first)
>*/
>   *(int *)ptr = tmp;
>  
> +if (page_bad) printf("pb 0x%lx\n", pa);
>  skip_memtest:
>   /*
>* Adjust array of valid/good pages.

PS: memtest86 hung at test 128-130G (server have 128G installed).
___
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: Enabling NUMA in BIOS stop booting FreeBSD

[Konstantin Belousov]

On Thu, Dec 15, 2016 at 01:51:18PM +0300, Slawa Olhovchenkov wrote:
> On Wed, Dec 14, 2016 at 09:03:49PM +0200, Konstantin Belousov wrote:
> 
> > So my opinion did not changed, this sounds like firmware problem.
> > I do not see how can I drill into it more.
> 
> I am don't know how it related. msgbufp mapped different with and w/o
> memory test:
> 
> w/o memory test, hang:
> msgbufp=0xf8207ff0 pa_indx=7 phys_avail[pa_indx]=207ff0
> 
> w/ memory test, boot:
> msgbufp=0xf8203ff0 pa_indx=7 phys_avail[pa_indx]=203ff0
Interesting.

Can you show me
- the output of the smap command from the loader (yes, I know it was already
  shown, I want it in the same mail as the data below for convenience);
- the output of sysctl machdep.smap after the succesfull boot with the
  memtest enabled.
Possibly, the dmesg of the boot (with late_console=0) with this and only
this patch applied against stock HEAD.  This might be long.

diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
index 682307f5fe4..072c8d76acf 100644
--- a/sys/amd64/amd64/machdep.c
+++ b/sys/amd64/amd64/machdep.c
@@ -1400,6 +1400,7 @@ getmemsize(caddr_t kmdp, u_int64_t first)
 */
*(int *)ptr = tmp;
 
+if (page_bad) printf("pb 0x%lx\n", pa);
 skip_memtest:
/*
 * Adjust array of valid/good pages.
___
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: FreeBSD_HEAD_amd64_gcc - Build #1733 - Still Failing

[Dimitry Andric]

On 15 Dec 2016, at 12:03, jenkins-ad...@freebsd.org wrote:
> 
> FreeBSD_HEAD_amd64_gcc - Build #1733 - Still Failing:
> 
> Build information: 
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1733/
> Full change log: 
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1733/changes
> Full build log: 
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1733/console
...
> building shared library libprivatedevdctl.so.0
> /usr/local/bin/x86_64-portbld-freebsd10.1-g++ -isystem 
> /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include/c++/v1
>  -std=c++11 -nostdinc++ -isystem 
> /builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/include
>  
> -L/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib
>  
> -B/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp/usr/lib
>  
> --sysroot=/builds/FreeBSD_HEAD_amd64_gcc/obj/builds/FreeBSD_HEAD_amd64_gcc/tmp
>  -B/usr/local/x86_64-freebsd/bin/  -fstack-protector-strong -shared -Wl,-x 
> -Wl,--fatal-warnings -Wl,--warn-shared-textrel  -o 
> libprivatedevdctl.so.0.full -Wl,-soname,libprivatedevdctl.so.0  
> `NM='/usr/local/x86_64-freebsd/bin/nm' NMFLAGS='' lorder consumer.pico 
> event.pico event_factory.pico exception.pico guid.pico |  tsort -q`
> /usr/local/bin/x86_64-freebsd-ld: cannot find -lstdc++

Dear Jenkins admins, can you please install a more recent version of
amd64-xtoolchain-gcc on the slave?  This is required to avoid the above
error about not being able to find libstdc++.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Enabling NUMA in BIOS stop booting FreeBSD

[Slawa Olhovchenkov]

On Wed, Dec 14, 2016 at 09:03:49PM +0200, Konstantin Belousov wrote:

> So my opinion did not changed, this sounds like firmware problem.
> I do not see how can I drill into it more.

I am don't know how it related. msgbufp mapped different with and w/o
memory test:

w/o memory test, hang:
msgbufp=0xf8207ff0 pa_indx=7 phys_avail[pa_indx]=207ff0

w/ memory test, boot:
msgbufp=0xf8203ff0 pa_indx=7 phys_avail[pa_indx]=203ff0

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