Re: BPi-M3 under stable/11 details: boots but with only 4 cores used for SMP --of 8 cores present. . .

[Mark Millard]

On 2016-Oct-24, at 2:00 PM, Emmanuel Vadot  wrote:


> Hello Mark,
> 
> The A83T is BIG/Little IIRC and we don't support that. That's why you
> only see 4 cores on the 8.

That is not what I get from reading the A83T documentation. All the CPU 
references are to the same type of CPU for each of the 8. But there is a 
NUMA-ish pair of "clusters" of "CPU"s without a common L2-cache or other cache 
across the clusters.

http://linux-sunxi.org/A83T says . . .

> This SoC does NOT comply with the ARM big.LITTLE architecture, therefore it 
> is in no way energy efficent and gets very hot.


> CPU:
>   • ARM Cortex-A7 Octa-Core


A83T_Datasheet_v1.3_20150510.pdf says:

> Main features of A83T include:
> • CPU architecture: Based on an octa-core CortexTM-A7 CPU architecture, . . ..


> 2.1. CPU Architecture
> 
>   • ARMv7 ISA standard instruction set plus Thumb-2 and Jazeller RCT
> 
>   • NEON with SIMD and VFPv4
> 
>   • Support LPAE
> 
>   • 32KB I-cache and 32KB D-cache per CPU
> 
>   • 1MB L2-cache

The "A883T Block Diagram (Figure 3-1 page labeled 12) simply says "A7 x 8".

A83T_User_Manual_v1.5.1_20150513.pdf has some more detailed diagrams and more 
information. . .

There are two CPU Clusters (0 and  1). It is more of a NUMA context due to 
caching within each cluster that is not across the clusters. This document's 
wording is more explicit, mentioning clusters for the L2-cache level (page 
labeled 51) in even its basic description of caches in the A83T archtiecture:

> 2.1.1. CPU Architecture
> 
> The A83T platform is based on octa-core CortexTM-A7 CPU architecture.
> 
>   •   ARMv7 ISA standard instruction set plus Thumb-2 and Jazeller RCT
> 
>   •   NEON with SIMD and VFPv4 support
> 
>   •   Support LPAE
> 
>   •   32KB I-cache and 32KB D-cache per CPU
> 
>   •   1MB L2-cache(512KB per Cluster)


See this document's Figure 3-1 "System Bus Tree" (on the page labeled 66).

From what I read one can control clock frequencies per cluster but it is 
allowed to have them both the same all the time that frequencies are stable for 
a while.

And I'll stop with the details that I see with that.

There may be some folks around with knowledge of more detail that might well be 
able to say "but it is not NUMA like for these details . . .". By no mean have 
I analyzed all the consequences of all the details.

But I find no evidence of BIG/Little use of different classes of cores at 
necessarily different cock rates and the like. As much as I've looked at looks 
more symmetric than that.



> cpulist0 shows 8 core because every core in is the dtb.
> 
> On Mon, 24 Oct 2016 09:04:35 -0700
> Mark Millard  wrote:
> 
>> The is for a Banana Pi M3 V1.2 board with the barrel power connector. The 5V 
>> 2A supply that I had to fit the barrel hole can not power the board 
>> sufficiently to boot --even when no fan is being powered. In order to boot 
>> with a fan I have both that and an official rpi3 power supply plugged in. 
>> The rpi3 power supply will not power the GPIO fan connections but can boot 
>> the board by itself (V5.1v and 2.5A but cell phone charger 
>> cabling/connections). I've got a heat sink on the CPU as well.
>> 
>>> root@bananapi-m3:~ # uname -apKU
>>> FreeBSD bananapi-m3 11.0-STABLE FreeBSD 11.0-STABLE #0 r307797M: Mon Oct 24 
>>> 00:41:16 PDT 2016 
>>> markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/ALLWINNER
>>>   arm armv6 1100505 1
>>> 100505
>> 
>>> root@bananapi-m3:~ # freebsd-version -ku
>>> 11.0-STABLE
>>> 11.0-STABLE
>> 
>> In the below note that "FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs" 
>> but cpulist0 shows cpu0 through cpu7. For now: So much for seeing how 
>> buildworld/buildkernel would go using all 8 cores.
>> 
>> (Note: the serial connection tends to drop some text sometimes. That may 
>> have happened some for the below.)
>> 
>>> root@bananapi-m3:~ # dmesg | more
>>> Copyright (c) 1992-2016 The FreeBSD Project.
>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>>>   The Regents of the University of California. All rights reserved.
>>> FreeBSD is a registered trademark of The FreeBSD Foundation.
>>> FreeBSD 11.0-STABLE #0 r307797M: Mon Oct 24 00:41:16 PDT 2016
>>>   
>>> markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/ALLWINNER
>>>  arm
>>> FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 
>>> 3.8.0)
>>> VT: init without driver.
>>> CPU: Cortex A7 rev 5 (Cortex-A core)
>>> Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext
>>> WB enabled LABT branch prediction disabled
>>> LoUU:2 LoC:3 LoUIS:2 
>>> Cache level 1: 
>>> 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc
>>> 32KB/32B 2-way instruction cache Read-Alloc
>>> Cache level 2: 
>>> 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc
>>> real memory  = 2147483648 (2048 MB)
>>> avail memory = 2090852352 (1993 MB)
>>> 

Re: BPi-M3 under stable/11 details: boots but with only 4 cores used for SMP --of 8 cores present. . .

[Mark Millard]

> On 2016-Oct-24, at 3:47 PM, Emmanuel Vadot  wrote:
> 
> 
> Ah yes, well same thing, we don't support cluster :)

I wonder if the second cluster is well powered down (as best it can be as early 
as it can be). I could not even boot without special power connections (beyond 
2A supply for the 5V/5.1V used). 2.5A worked (no fan to power). It took two 
supplies to also provide fan power over a couple of the GPIO pins and still be 
able to boot.

And, yes, reading about the A83T does suggest that FreeBSD will never put that 
kind of NUMA handling effort into it, like it does for some bigger iron that is 
far more in use.

It would probably be a good idea if wiki pages and such referencing the A83T 
and its status be explicit about the "at most 4 cores in use" status. Using 
more than 4 cores is the primary reason to get/use a A83T (and to put up with 
handling power and heat issues).

> On Mon, 24 Oct 2016 15:42:40 -0700
> Mark Millard  wrote:
> 
>> On 2016-Oct-24, at 2:00 PM, Emmanuel Vadot  wrote:
>> 
>> 
>>> Hello Mark,
>>> 
>>> The A83T is BIG/Little IIRC and we don't support that. That's why you
>>> only see 4 cores on the 8.
>> 
>> That is not what I get from reading the A83T documentation. All the CPU 
>> references are to the same type of CPU for each of the 8. But there is a 
>> NUMA-ish pair of "clusters" of "CPU"s without a common L2-cache or other 
>> cache across the clusters.
>> 
>> http://linux-sunxi.org/A83T says . . .
>> 
>>> This SoC does NOT comply with the ARM big.LITTLE architecture, therefore it 
>>> is in no way energy efficent and gets very hot.
>> 
>> 
>>> CPU:
>>> ? ARM Cortex-A7 Octa-Core
>> 
>> 
>> A83T_Datasheet_v1.3_20150510.pdf says:
>> 
>>> Main features of A83T include:
>>> ? CPU architecture: Based on an octa-core CortexTM-A7 CPU architecture, . . 
>>> ..
>> 
>> 
>>> 2.1. CPU Architecture
>>> 
>>> ? ARMv7 ISA standard instruction set plus Thumb-2 and Jazeller RCT
>>> 
>>> ? NEON with SIMD and VFPv4
>>> 
>>> ? Support LPAE
>>> 
>>> ? 32KB I-cache and 32KB D-cache per CPU
>>> 
>>> ? 1MB L2-cache
>> 
>> The "A883T Block Diagram (Figure 3-1 page labeled 12) simply says "A7 x 8".
>> 
>> A83T_User_Manual_v1.5.1_20150513.pdf has some more detailed diagrams and 
>> more information. . .
>> 
>> There are two CPU Clusters (0 and  1). It is more of a NUMA context due to 
>> caching within each cluster that is not across the clusters. This document's 
>> wording is more explicit, mentioning clusters for the L2-cache level (page 
>> labeled 51) in even its basic description of caches in the A83T archtiecture:
>> 
>>> 2.1.1. CPU Architecture
>>> 
>>> The A83T platform is based on octa-core CortexTM-A7 CPU architecture.
>>> 
>>> ? ?  ARMv7 ISA standard instruction set plus Thumb-2 and Jazeller RCT
>>> 
>>> ? ?  NEON with SIMD and VFPv4 support
>>> 
>>> ? ?  Support LPAE
>>> 
>>> ? ?  32KB I-cache and 32KB D-cache per CPU
>>> 
>>> ? ?  1MB L2-cache(512KB per Cluster)
>> 
>> 
>> See this document's Figure 3-1 "System Bus Tree" (on the page labeled 66).
>> 
>> From what I read one can control clock frequencies per cluster but it is 
>> allowed to have them both the same all the time that frequencies are stable 
>> for a while.
>> 
>> And I'll stop with the details that I see with that.
>> 
>> There may be some folks around with knowledge of more detail that might well 
>> be able to say "but it is not NUMA like for these details . . .". By no mean 
>> have I analyzed all the consequences of all the details.
>> 
>> But I find no evidence of BIG/Little use of different classes of cores at 
>> necessarily different cock rates and the like. As much as I've looked at 
>> looks more symmetric than that.
>> 
>> 
>> 
>>> cpulist0 shows 8 core because every core in is the dtb.
>>> 
>>> On Mon, 24 Oct 2016 09:04:35 -0700
>>> Mark Millard  wrote:
>>> 
 The is for a Banana Pi M3 V1.2 board with the barrel power connector. The 
 5V 2A supply that I had to fit the barrel hole can not power the board 
 sufficiently to boot --even when no fan is being powered. In order to boot 
 with a fan I have both that and an official rpi3 power supply plugged in. 
 The rpi3 power supply will not power the GPIO fan connections but can boot 
 the board by itself (V5.1v and 2.5A but cell phone charger 
 cabling/connections). I've got a heat sink on the CPU as well.
 
> root@bananapi-m3:~ # uname -apKU
> FreeBSD bananapi-m3 11.0-STABLE FreeBSD 11.0-STABLE #0 r307797M: Mon Oct 
> 24 00:41:16 PDT 2016 
> markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/ALLWINNER
>   arm armv6 1100505 1
> 100505
 
> root@bananapi-m3:~ # freebsd-version -ku
> 11.0-STABLE
> 11.0-STABLE
 
 In the below note that "FreeBSD/SMP: Multiprocessor System Detected: 4 
 CPUs" but cpulist0 shows cpu0 through cpu7. For now: So much for seeing 
 how buildworld/buildkernel would go 

Re: BPi-M3 under stable/11 details: boots but with only 4 cores used for SMP --of 8 cores present. . .

[Emmanuel Vadot]

 Ah yes, well same thing, we don't support cluster :)

On Mon, 24 Oct 2016 15:42:40 -0700
Mark Millard  wrote:

> On 2016-Oct-24, at 2:00 PM, Emmanuel Vadot  wrote:
> 
> 
> > Hello Mark,
> > 
> > The A83T is BIG/Little IIRC and we don't support that. That's why you
> > only see 4 cores on the 8.
> 
> That is not what I get from reading the A83T documentation. All the CPU 
> references are to the same type of CPU for each of the 8. But there is a 
> NUMA-ish pair of "clusters" of "CPU"s without a common L2-cache or other 
> cache across the clusters.
> 
> http://linux-sunxi.org/A83T says . . .
> 
> > This SoC does NOT comply with the ARM big.LITTLE architecture, therefore it 
> > is in no way energy efficent and gets very hot.
> 
> 
> > CPU:
> > ? ARM Cortex-A7 Octa-Core
> 
> 
> A83T_Datasheet_v1.3_20150510.pdf says:
> 
> > Main features of A83T include:
> > ? CPU architecture: Based on an octa-core CortexTM-A7 CPU architecture, . . 
> > ..
> 
> 
> > 2.1. CPU Architecture
> > 
> > ? ARMv7 ISA standard instruction set plus Thumb-2 and Jazeller RCT
> > 
> > ? NEON with SIMD and VFPv4
> > 
> > ? Support LPAE
> > 
> > ? 32KB I-cache and 32KB D-cache per CPU
> > 
> > ? 1MB L2-cache
> 
> The "A883T Block Diagram (Figure 3-1 page labeled 12) simply says "A7 x 8".
> 
> A83T_User_Manual_v1.5.1_20150513.pdf has some more detailed diagrams and more 
> information. . .
> 
> There are two CPU Clusters (0 and  1). It is more of a NUMA context due to 
> caching within each cluster that is not across the clusters. This document's 
> wording is more explicit, mentioning clusters for the L2-cache level (page 
> labeled 51) in even its basic description of caches in the A83T archtiecture:
> 
> > 2.1.1. CPU Architecture
> > 
> > The A83T platform is based on octa-core CortexTM-A7 CPU architecture.
> > 
> > ? ?  ARMv7 ISA standard instruction set plus Thumb-2 and Jazeller RCT
> > 
> > ? ?  NEON with SIMD and VFPv4 support
> > 
> > ? ?  Support LPAE
> > 
> > ? ?  32KB I-cache and 32KB D-cache per CPU
> > 
> > ? ?  1MB L2-cache(512KB per Cluster)
> 
> 
> See this document's Figure 3-1 "System Bus Tree" (on the page labeled 66).
> 
> From what I read one can control clock frequencies per cluster but it is 
> allowed to have them both the same all the time that frequencies are stable 
> for a while.
> 
> And I'll stop with the details that I see with that.
> 
> There may be some folks around with knowledge of more detail that might well 
> be able to say "but it is not NUMA like for these details . . .". By no mean 
> have I analyzed all the consequences of all the details.
> 
> But I find no evidence of BIG/Little use of different classes of cores at 
> necessarily different cock rates and the like. As much as I've looked at 
> looks more symmetric than that.
> 
> 
> 
> > cpulist0 shows 8 core because every core in is the dtb.
> > 
> > On Mon, 24 Oct 2016 09:04:35 -0700
> > Mark Millard  wrote:
> > 
> >> The is for a Banana Pi M3 V1.2 board with the barrel power connector. The 
> >> 5V 2A supply that I had to fit the barrel hole can not power the board 
> >> sufficiently to boot --even when no fan is being powered. In order to boot 
> >> with a fan I have both that and an official rpi3 power supply plugged in. 
> >> The rpi3 power supply will not power the GPIO fan connections but can boot 
> >> the board by itself (V5.1v and 2.5A but cell phone charger 
> >> cabling/connections). I've got a heat sink on the CPU as well.
> >> 
> >>> root@bananapi-m3:~ # uname -apKU
> >>> FreeBSD bananapi-m3 11.0-STABLE FreeBSD 11.0-STABLE #0 r307797M: Mon Oct 
> >>> 24 00:41:16 PDT 2016 
> >>> markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/ALLWINNER
> >>>   arm armv6 1100505 1
> >>> 100505
> >> 
> >>> root@bananapi-m3:~ # freebsd-version -ku
> >>> 11.0-STABLE
> >>> 11.0-STABLE
> >> 
> >> In the below note that "FreeBSD/SMP: Multiprocessor System Detected: 4 
> >> CPUs" but cpulist0 shows cpu0 through cpu7. For now: So much for seeing 
> >> how buildworld/buildkernel would go using all 8 cores.
> >> 
> >> (Note: the serial connection tends to drop some text sometimes. That may 
> >> have happened some for the below.)
> >> 
> >>> root@bananapi-m3:~ # dmesg | more
> >>> Copyright (c) 1992-2016 The FreeBSD Project.
> >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> >>>   The Regents of the University of California. All rights reserved.
> >>> FreeBSD is a registered trademark of The FreeBSD Foundation.
> >>> FreeBSD 11.0-STABLE #0 r307797M: Mon Oct 24 00:41:16 PDT 2016
> >>>   
> >>> markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/ALLWINNER
> >>>  arm
> >>> FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on 
> >>> LLVM 3.8.0)
> >>> VT: init without driver.
> >>> CPU: Cortex A7 rev 5 (Cortex-A core)
> >>> Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 

Re: BPi-M3 under stable/11 details: boots but with only 4 cores used for SMP --of 8 cores present. . .

[Emmanuel Vadot]

 Hello Mark,

 The A83T is BIG/Little IIRC and we don't support that. That's why you
only see 4 cores on the 8.
 cpulist0 shows 8 core because every core in is the dtb.

On Mon, 24 Oct 2016 09:04:35 -0700
Mark Millard  wrote:

> The is for a Banana Pi M3 V1.2 board with the barrel power connector. The 5V 
> 2A supply that I had to fit the barrel hole can not power the board 
> sufficiently to boot --even when no fan is being powered. In order to boot 
> with a fan I have both that and an official rpi3 power supply plugged in. The 
> rpi3 power supply will not power the GPIO fan connections but can boot the 
> board by itself (V5.1v and 2.5A but cell phone charger cabling/connections). 
> I've got a heat sink on the CPU as well.
> 
> > root@bananapi-m3:~ # uname -apKU
> > FreeBSD bananapi-m3 11.0-STABLE FreeBSD 11.0-STABLE #0 r307797M: Mon Oct 24 
> > 00:41:16 PDT 2016 
> > markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/ALLWINNER
> >   arm armv6 1100505 1
> > 100505
> 
> > root@bananapi-m3:~ # freebsd-version -ku
> > 11.0-STABLE
> > 11.0-STABLE
> 
> In the below note that "FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs" 
> but cpulist0 shows cpu0 through cpu7. For now: So much for seeing how 
> buildworld/buildkernel would go using all 8 cores.
> 
> (Note: the serial connection tends to drop some text sometimes. That may have 
> happened some for the below.)
> 
> > root@bananapi-m3:~ # dmesg | more
> > Copyright (c) 1992-2016 The FreeBSD Project.
> > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> >The Regents of the University of California. All rights reserved.
> > FreeBSD is a registered trademark of The FreeBSD Foundation.
> > FreeBSD 11.0-STABLE #0 r307797M: Mon Oct 24 00:41:16 PDT 2016
> >
> > markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/ALLWINNER
> >  arm
> > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 
> > 3.8.0)
> > VT: init without driver.
> > CPU: Cortex A7 rev 5 (Cortex-A core)
> > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext
> > WB enabled LABT branch prediction disabled
> > LoUU:2 LoC:3 LoUIS:2 
> > Cache level 1: 
> > 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc
> > 32KB/32B 2-way instruction cache Read-Alloc
> > Cache level 2: 
> > 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc
> > real memory  = 2147483648 (2048 MB)
> > avail memory = 2090852352 (1993 MB)
> > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
> > random: entropy device external interface
> > kbd0 at kbdmux0
> > ofwbus0: 
> > aw_ccu0:  on ofwbus0
> > clk_fixed0:  on aw_ccu0
> > clk_fixed1:  mem 0x1c20028-0x1c2002b on aw_ccu0
> > clk_fixed3:  on aw_ccu0
> > aw_ahbclk0:  mem 0x1c20054-0x1c20057 on aw_ccu0
> > aw_apbclk0:  mem 0x1c20054-0x1c20057 on aw_ccu0
> > aw_apbclk1:  mem 0x1c20058-0x1c2005b on aw_ccu0
> > aw_ahbclk1:  mem 0x1c2005c-0x1c2005f on aw_ccu0
> > aw_gate0:  mem 0x1c20060-0x1c2006f on aw_ccu0
> > aw_mmcclk0:  mem 0x1c20088-0x1c2clk1:  > Clock> mem 0x1c2008c-0x1c2008f on aw_ccu0
> > aw_mmcclk2:  mem 0x1c20090-0x1c20093 on aw_ccu0
> > aw_cpusclk0:  mem 0x1f01400-0x1f01403 on aw_ccu0
> > clk_fixed4:  on aw_ccu0
> > aw_apbclk2:  mem 0x1f0140c-0x1f0140f on aw_ccu0
> > aw_gate1:  mem 0x1f01428-0x1f0142b on aw_ccu0
> > aw_pll1:  mem 0x1c20044-0x1c20047 on aw_ccu0
> > aw_usbclk0:  mem 0x1c200cc-0x1c200cf on aw_ccu0
> > clk_fixed5:  mem 0x1c00030-0x1c00033 on aw_ccu0
> > simplebus0:  on ofwbus0
> > aw_reset0:  mem 0x1c202c0-0x1c202cb on simplebus0
> > aw_reset1:  mem 0x1c202d0-0x1c202d3 on simplebus0
> > aw_reset2:  mem 0x1c202d8-0x1c202db on simplebus0
> > aw_reset3:  mem 0x1f014b0-0x1f014b3 on simplebus0
> > iichb0:  mem 0x1c2ac00-0x1c2afff 
> > on simplebus0
> > iicbus0: hb0
> > iichb1:  mem 0x1c2b000-0x1c2b3ff 
> > on simplebus0
> > iicbus1:  on iichb1
> > iichb2:  mem 0x1c2b400-0x1c2b7ff 
> > on simplebus0
> > iicbus2:  on iichb2
> > regfix0:  on ofwbus0
> > regfix1:  on ofwbus0
> > regfix2:  on ofwbus0
> > regfix3:  on ofwbus0
> > regfix4:  on ofwbus0
> > aw_sid0:  mem 0x1c14000-0x1c143ff on 
> > simplebus0
> > awusbphy0:  on simplebu,0x1c86000-0x1c87fff on simplebus0
> > gic0: pn 0x20, arch 0x2, rev 0x1, implementer 0x43b irqs 224
> > gpio0:  mem 0x1c20800-0x1c20bff on 
> > simplebus0
> > gpiobus0:  on gpio0
> > gpio1:  mem 0x1f02c00-0x1f02fff on 
> > simplebus0
> > gpiobus1:  on gpio1
> > aw_nmi0:  mem 0x1f00c0c-0x1f00c43 on simplebus0
> > generic_timer0:  on ofwbus0
> > Timecounter "cy 2400 Hz quality 1000
> > Event timer "ARM MPCore Eventtimer" frequency 2400 Hz quality 1000
> > cpulist0:  on ofwbus0
> > cpu0:  on cpulist0
> > cpu1:  on cpulist0
> > cpu2:  on cpulist0
> > cpu3:  on cpulist0
> > cpu4:  on cpulist0
> > cpu5:  on cpulist0
> > cpu6:  on cpulist0
> > cpu7:  on cpulist0
> > a10_mmc0:  mem 0x1c0f000-0x1c0 
> > on simplebus0
> > mmc0:  on a10_mmc0
> > a10_mmc1:  mem 0x1c11000-0x1c11fff 
> > on 

Re: moused(?) touchpad issue after updating to FreeBSD 11.0-STABLE #0 r307755 amd64

[Jakub Lach]

$ moused -d -i all -p /dev/psm0 
moused: proto params: f8 80 00 00 8 00 ff
/dev/psm0 ps/2 sysmouse Synaptics Touchpad




--
View this message in context: 
http://freebsd.1045724.x6.nabble.com/moused-touchpad-issue-after-updating-to-FreeBSD-11-0-STABLE-0-r307755-amd64-tp6138663p6139267.html
Sent from the freebsd-stable mailing list archive at Nabble.com.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: moused(?) touchpad issue after updating to FreeBSD 11.0-STABLE #0 r307755 amd64

[Jakub Lach]

It looks to me, that something in this commit-

https://svnweb.freebsd.org/base?view=revision=307576

forced me to explicitly set extended synaptics support- 

hw.psm.synaptics_support: 1

to use normal tapping. It works now, albeit with all additional
synaptics extensions.




--
View this message in context: 
http://freebsd.1045724.x6.nabble.com/moused-touchpad-issue-after-updating-to-FreeBSD-11-0-STABLE-0-r307755-amd64-tp6138663p6139235.html
Sent from the freebsd-stable mailing list archive at Nabble.com.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: bsnmpd going crazy on 10-STABLE

[Florian Smeets via freebsd-stable]

On 24/10/2016 19:15, Zane C. B-H. wrote:
> On Mon, 24 Oct 2016 12:05:52 -0500
> "Zane C. B-H."  wrote:
> 
>> 
> 
> Commenting out the line below seems to have fixed it on the system in
> question...
> 
> begemotSnmpdModulePath."hostres" = "/usr/lib/snmp_hostres.so"
> 
> Not sure why it is not behaving on only one 10-STABLE system.

You need the patch from [1] unfortunately nobody committed it, yet.
According the the PR it seems to be somewhat of a workaround.

I have been running with it for 3 months now on stable/11.

HTH,
Florian

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209368



signature.asc
Description: OpenPGP digital signature

Re: zfs, a directory that used to hold lot of files and listing pause

[Jamie Landeg-Jones]

Scott Bennett  wrote:

> thousand blocks allocated.  Directories don't shrink.  Directory entries do
> not get moved around within directories when files are added or deleted.
> Directories can remain the same length or they can grow in length.  If a
> directory once had many tens of thousands of filenames and links to their
> primary inodes, then the directory is still that big, even if it now only
> contains two [+ 20 to 30 directory], probably widely separated, entries.

> IOW, if you want the performance to go back to what it was when the directory
> was fresh (and still small), you have to create a new directory and then move
> the remaining entries from the old directory into the new (small) directory.

Not entirely true. FreeBSD on UFS *will* *truncate* directories where possible,
each time a new directory entry is made, and there is contiguous unused space
to the end of the directory-file.

 [ As an aside, tmpfs does 'defragment' and rezise directories
   in real time, when a file from *any* location is deleted.   ]

Back to UFS (I don't know about ZFS):

So, whilst you are right about directory entries not being moved around,
consider the following. Note the size of '.' in each directory listing: 

| 17:05 [2] (1) "~" jamie@lapcat% md dir
| dir
|
| 17:05 [2] (2) "~" jamie@lapcat% cd dir
|
| 17:05 [2] (3) "~/dir" jamie@lapcat% l
| total 8
| 4 drwxr-xr-x   2 jamie  jamie  -  512 24 Oct 17:05 ./
| 4 drwx--  72 jamie  jamie  - 3072 24 Oct 17:05 ../
|
| 17:05 [2] (4) "~/dir" jamie@lapcat% jot 999 1 999 | awk '{printf "touch 
%03d\n", $1}' | sh
|
| 17:05 [2] (5) "~/dir" jamie@lapcat% l | head
| total 16
| 12 drwxr-xr-x   2 jamie  jamie  - 12288 24 Oct 17:05 ./
|  4 drwx--  72 jamie  jamie  -  3072 24 Oct 17:05 ../
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 001
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 002
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 003
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 004
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 005
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 006
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 007
|
| *141* 17:05 [2] (6) "~/dir" jamie@lapcat% rm [678]*
| remove 300 files? y
|
| 17:06 [2] (7) "~/dir" jamie@lapcat% l | head
| total 16
| 12 drwxr-xr-x   2 jamie  jamie  - 12288 24 Oct 17:06 ./
|  4 drwx--  72 jamie  jamie  -  3072 24 Oct 17:05 ../
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 001
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 002
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 003
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 004
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 005
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 006
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 007
|
| *141* 17:06 [2] (8) "~/dir" jamie@lapcat% touch x; rm x
|
| 17:06 [2] (9) "~/dir" jamie@lapcat% l | head
| total 16
| 12 drwxr-xr-x   2 jamie  jamie  - 12288 24 Oct 17:06 ./
|  4 drwx--  72 jamie  jamie  -  3072 24 Oct 17:05 ../
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 001
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 002
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 003
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 004
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 005
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 006
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 007
|
| *141* 17:06 [2] (10) "~/dir" jamie@lapcat% rm 9*
| remove 100 files? y
|
| 17:06 [2] (11) "~/dir" jamie@lapcat% l | head
| total 16
| 12 drwxr-xr-x   2 jamie  jamie  - 12288 24 Oct 17:06 ./
|  4 drwx--  72 jamie  jamie  -  3072 24 Oct 17:05 ../
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 001
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 002
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 003
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 004
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 005
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 006
|  0 -rw-r--r--   1 jamie  jamie  - 0 24 Oct 17:05 007
|
| *141* 17:06 [2] (12) "~/dir" jamie@lapcat% touch x ; rm x
|
| 17:06 [2] (13) "~/dir" jamie@lapcat% l | head
| total 12
| 8 drwxr-xr-x   2 jamie  jamie  - 7680 24 Oct 17:06 ./
| 4 drwx--  72 jamie  jamie  - 3072 24 Oct 17:05 ../
| 0 -rw-r--r--   1 jamie  jamie  -0 24 Oct 17:05 001
| 0 -rw-r--r--   1 jamie  jamie  -0 24 Oct 17:05 002
| 0 -rw-r--r--   1 jamie  jamie  -0 24 Oct 17:05 003
| 0 -rw-r--r--   1 jamie  jamie  -0 24 Oct 17:05 004
| 0 -rw-r--r--   1 jamie  jamie  -0 24 Oct 17:05 005
| 0 -rw-r--r--   1 jamie  jamie  -0 24 Oct 17:05 006
| 0 -rw-r--r--   1 jamie  jamie  -0 24 Oct 17:05 007
|
| *141* 17:06 [2] (14) "~/dir" jamie@lapcat% rm *
| remove 599 files? y
|
| 17:06 [2] (15) "~/dir" jamie@lapcat% l
| total 12
| 8 drwxr-xr-x   2 jamie  jamie  - 7680 24 Oct 17:06 ./
| 4 

Re: bsnmpd going crazy on 10-STABLE

[Zane C. B-H.]

On Mon, 24 Oct 2016 12:05:52 -0500
"Zane C. B-H."  wrote:

> 

Commenting out the line below seems to have fixed it on the system in
question...

begemotSnmpdModulePath."hostres" = "/usr/lib/snmp_hostres.so"

Not sure why it is not behaving on only one 10-STABLE system.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

bsnmpd going crazy on 10-STABLE

[Zane C. B-H.]

Restarted a machine and post restart I began seeing the stuff below
when watch it via truss. It just keeps looping over and over doing
stuff like that while eating up lots of CPU time.

I've checked the configs between both machines and they are both the
same. I've tried updating usr.sbin/bsnmpd and lib/libbsnmp to the
newest versions, but that seems to have zero affect on it.

Any thoughts?

openat(AT_FDCWD,"/dev/da2",O_NONBLOCK,00)= 16 (0x10)
ioctl(16,0x40086481 { IOR 0x64('d'), 129, 8 },0xb578) = 0 (0x0)
__sysctl(0x7fffb480,0x2,0x7fffb4bc,0x7fffb4b0,0x8055b7eaa,0x11) = 0 
(0x0)
__sysctl(0x7fffb4bc,0x3,0x0,0x7fffb4c8,0x0,0x0) = 0 (0x0)
__sysctl(0x7fffb4bc,0x3,0x8066c9000,0x7fffb4c8,0x0,0x0) = 0 (0x0)
gettimeofday({ 1477327808.091871 },0x0)  = 0 (0x0)
getpid() = 42507 (0xa60b)
close(16)= 0 (0x0)
openat(AT_FDCWD,"/dev/da1",O_NONBLOCK,00)= 16 (0x10)
ioctl(16,0x40086481 { IOR 0x64('d'), 129, 8 },0xb578) = 0 (0x0)
__sysctl(0x7fffb480,0x2,0x7fffb4bc,0x7fffb4b0,0x8055b7eaa,0x11) = 0 
(0x0)
__sysctl(0x7fffb4bc,0x3,0x0,0x7fffb4c8,0x0,0x0) = 0 (0x0)
__sysctl(0x7fffb4bc,0x3,0x8066c9000,0x7fffb4c8,0x0,0x0) = 0 (0x0)
gettimeofday({ 1477327808.096923 },0x0)  = 0 (0x0)
getpid() = 42507 (0xa60b)
close(16)= 0 (0x0)
openat(AT_FDCWD,"/dev/da0",O_NONBLOCK,00)= 16 (0x10)
ioctl(16,0x40086481 { IOR 0x64('d'), 129, 8 },0xb578) = 0 (0x0)
__sysctl(0x7fffb480,0x2,0x7fffb4bc,0x7fffb4b0,0x8055b7eaa,0x11) = 0 
(0x0)
__sysctl(0x7fffb4bc,0x3,0x0,0x7fffb4c8,0x0,0x0) = 0 (0x0)
__sysctl(0x7fffb4bc,0x3,0x8066c9000,0x7fffb4c8,0x0,0x0) = 0 (0x0)
gettimeofday({ 1477327808.102461 },0x0)  = 0 (0x0)
getpid() = 42507 (0xa60b)
close(16)= 0 (0x0)
openat(AT_FDCWD,"/dev/cd0",O_NONBLOCK,00)= 16 (0x10)
ioctl(16,0x40086481 { IOR 0x64('d'), 129, 8 },0xb578) ERR#2 'No such file 
or directory'
close(16)= 0 (0x0)
gettimeofday({ 1477327808.109391 },0x0)  = 0 (0x0)
gettimeofday({ 1477327808.109529 },0x0)  = 0 (0x0)
select(16,{ 6 12 14 15 },{ },{ },{ 0.155257 })   = 1 (0x1)
read(12,"!system=CAM subsystem=periph typ"...,512) = 167 (0xa7)
__sysctl(0x7fffb4f0,0x2,0x7fffb530,0x7fffb528,0x8053b3586,0xb) = 0 
(0x0)
__sysctl(0x7fffb530,0x3,0x7fffb618,0x7fffb610,0x0,0x0) = 0 (0x0)
__sysctl(0x7fffb6b8,0x2,0x7fffb620,0x7fffb850,0x8053b365e,0xe) = 0 
(0x0)
__sysctl(0x7fffb620,0x5,0x7fffb6c0,0x7fffb848,0x0,0x0) = 0 (0x0)
__sysctl(0x7fffb620,0x5,0x7fffb6c0,0x7fffb848,0x0,0x0) = 0 (0x0)
__sysctl(0x7fffb620,0x5,0x7fffb6c0,0x7fffb848,0x0,0x0) = 0 (0x0)
__sysctl(0x7fffb620,0x5,0x7fffb6c0,0x7fffb848,0x0,0x0) = 0 (0x0)
__sysctl(0x7fffb620,0x5,0x7fffb6c0,0x7fffb848,0x0,0x0) = 0 (0x0)
__sysctl(0x7fffb620,0x5,0x7fffb6c0,0x7fffb848,0x0,0x0) = 0 (0x0)
__sysctl(0x7fffb620,0x5,0x7fffb6c0,0x7fffb848,0x0,0x0) = 0 (0x0)
__sysctl(0x7fffb620,0x5,0x7fffb6c0,0x7fffb848,0x0,0x0) = 0 (0x0)
__sysctl(0x7fffb620,0x5,0x7fffb6c0,0x7fffb848,0x0,0x0) = 0 (0x0)
__sysctl(0x7fffb620,0x5,0x7fffb6c0,0x7fffb848,0x0,0x0) = 0 (0x0)
__sysctl(0x7fffb620,0x5,0x7fffb6c0,0x7fffb848,0x0,0x0) = 0 (0x0)
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

bsnmpd going crazy on 10-STABLE

[Zane C. B-H.]

Restarted a machine and post restart I began seeing the stuff below
when watch it via truss. It just keeps looping over and over doing
stuff like that while eating up lots of CPU time.

I've checked the configs between both machines and they are both the
same. I've tried updating usr.sbin/bsnmpd and lib/libbsnmp to the
newest versions, but that seems to have zero affect on it.

Any thoughts?

openat(AT_FDCWD,"/dev/da2",O_NONBLOCK,00)= 16 (0x10)
ioctl(16,0x40086481 { IOR 0x64('d'), 129, 8 },0xb578) = 0 (0x0)
__sysctl(0x7fffb480,0x2,0x7fffb4bc,0x7fffb4b0,0x8055b7eaa,0x11)
= 0 (0x0) __sysctl(0x7fffb4bc,0x3,0x0,0x7fffb4c8,0x0,0x0) = 0
(0x0) __sysctl(0x7fffb4bc,0x3,0x8066c9000,0x7fffb4c8,0x0,0x0)
= 0 (0x0) gettimeofday({ 1477327808.091871 },0x0)  = 0 (0x0)
getpid() = 42507 (0xa60b)
close(16)= 0 (0x0)
openat(AT_FDCWD,"/dev/da1",O_NONBLOCK,00)= 16 (0x10)
ioctl(16,0x40086481 { IOR 0x64('d'), 129, 8 },0xb578) = 0 (0x0)
__sysctl(0x7fffb480,0x2,0x7fffb4bc,0x7fffb4b0,0x8055b7eaa,0x11)
= 0 (0x0) __sysctl(0x7fffb4bc,0x3,0x0,0x7fffb4c8,0x0,0x0) = 0
(0x0) __sysctl(0x7fffb4bc,0x3,0x8066c9000,0x7fffb4c8,0x0,0x0)
= 0 (0x0) gettimeofday({ 1477327808.096923 },0x0)  = 0 (0x0)
getpid() = 42507 (0xa60b)
close(16)= 0 (0x0)
openat(AT_FDCWD,"/dev/da0",O_NONBLOCK,00)= 16 (0x10)
ioctl(16,0x40086481 { IOR 0x64('d'), 129, 8 },0xb578) = 0 (0x0)
__sysctl(0x7fffb480,0x2,0x7fffb4bc,0x7fffb4b0,0x8055b7eaa,0x11)
= 0 (0x0) __sysctl(0x7fffb4bc,0x3,0x0,0x7fffb4c8,0x0,0x0) = 0
(0x0) __sysctl(0x7fffb4bc,0x3,0x8066c9000,0x7fffb4c8,0x0,0x0)
= 0 (0x0) gettimeofday({ 1477327808.102461 },0x0)  = 0 (0x0)
getpid() = 42507 (0xa60b)
close(16)= 0 (0x0)
openat(AT_FDCWD,"/dev/cd0",O_NONBLOCK,00)= 16 (0x10)
ioctl(16,0x40086481 { IOR 0x64('d'), 129, 8 },0xb578) ERR#2 'No
such file or directory'
close(16)= 0 (0x0)
gettimeofday({ 1477327808.109391 },0x0)  = 0 (0x0)
gettimeofday({ 1477327808.109529 },0x0)  = 0 (0x0)
select(16,{ 6 12 14 15 },{ },{ },{ 0.155257 })   = 1 (0x1)
read(12,"!system=CAM subsystem=periph typ"...,512) = 167 (0xa7)
__sysctl(0x7fffb4f0,0x2,0x7fffb530,0x7fffb528,0x8053b3586,0xb)
= 0 (0x0)
__sysctl(0x7fffb530,0x3,0x7fffb618,0x7fffb610,0x0,0x0) =
0 (0x0)
__sysctl(0x7fffb6b8,0x2,0x7fffb620,0x7fffb850,0x8053b365e,0xe)
= 0 (0x0)
__sysctl(0x7fffb620,0x5,0x7fffb6c0,0x7fffb848,0x0,0x0) =
0 (0x0)
__sysctl(0x7fffb620,0x5,0x7fffb6c0,0x7fffb848,0x0,0x0) =
0 (0x0)
__sysctl(0x7fffb620,0x5,0x7fffb6c0,0x7fffb848,0x0,0x0) =
0 (0x0)
__sysctl(0x7fffb620,0x5,0x7fffb6c0,0x7fffb848,0x0,0x0) =
0 (0x0)
__sysctl(0x7fffb620,0x5,0x7fffb6c0,0x7fffb848,0x0,0x0) =
0 (0x0)
__sysctl(0x7fffb620,0x5,0x7fffb6c0,0x7fffb848,0x0,0x0) =
0 (0x0)
__sysctl(0x7fffb620,0x5,0x7fffb6c0,0x7fffb848,0x0,0x0) =
0 (0x0)
__sysctl(0x7fffb620,0x5,0x7fffb6c0,0x7fffb848,0x0,0x0) =
0 (0x0)
__sysctl(0x7fffb620,0x5,0x7fffb6c0,0x7fffb848,0x0,0x0) =
0 (0x0)
__sysctl(0x7fffb620,0x5,0x7fffb6c0,0x7fffb848,0x0,0x0) =
0 (0x0)
__sysctl(0x7fffb620,0x5,0x7fffb6c0,0x7fffb848,0x0,0x0) =
0 (0x0)
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

BPi-M3 under stable/11 details: boots but with only 4 cores used for SMP --of 8 cores present. . .

[Mark Millard]

The is for a Banana Pi M3 V1.2 board with the barrel power connector. The 5V 2A 
supply that I had to fit the barrel hole can not power the board sufficiently 
to boot --even when no fan is being powered. In order to boot with a fan I have 
both that and an official rpi3 power supply plugged in. The rpi3 power supply 
will not power the GPIO fan connections but can boot the board by itself (V5.1v 
and 2.5A but cell phone charger cabling/connections). I've got a heat sink on 
the CPU as well.

> root@bananapi-m3:~ # uname -apKU
> FreeBSD bananapi-m3 11.0-STABLE FreeBSD 11.0-STABLE #0 r307797M: Mon Oct 24 
> 00:41:16 PDT 2016 
> markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/ALLWINNER
>   arm armv6 1100505 1
> 100505

> root@bananapi-m3:~ # freebsd-version -ku
> 11.0-STABLE
> 11.0-STABLE

In the below note that "FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs" 
but cpulist0 shows cpu0 through cpu7. For now: So much for seeing how 
buildworld/buildkernel would go using all 8 cores.

(Note: the serial connection tends to drop some text sometimes. That may have 
happened some for the below.)

> root@bananapi-m3:~ # dmesg | more
> Copyright (c) 1992-2016 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 11.0-STABLE #0 r307797M: Mon Oct 24 00:41:16 PDT 2016
>
> markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/ALLWINNER
>  arm
> FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 
> 3.8.0)
> VT: init without driver.
> CPU: Cortex A7 rev 5 (Cortex-A core)
> Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext
> WB enabled LABT branch prediction disabled
> LoUU:2 LoC:3 LoUIS:2 
> Cache level 1: 
> 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc
> 32KB/32B 2-way instruction cache Read-Alloc
> Cache level 2: 
> 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc
> real memory  = 2147483648 (2048 MB)
> avail memory = 2090852352 (1993 MB)
> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
> random: entropy device external interface
> kbd0 at kbdmux0
> ofwbus0: 
> aw_ccu0:  on ofwbus0
> clk_fixed0:  on aw_ccu0
> clk_fixed1:  mem 0x1c20028-0x1c2002b on aw_ccu0
> clk_fixed3:  on aw_ccu0
> aw_ahbclk0:  mem 0x1c20054-0x1c20057 on aw_ccu0
> aw_apbclk0:  mem 0x1c20054-0x1c20057 on aw_ccu0
> aw_apbclk1:  mem 0x1c20058-0x1c2005b on aw_ccu0
> aw_ahbclk1:  mem 0x1c2005c-0x1c2005f on aw_ccu0
> aw_gate0:  mem 0x1c20060-0x1c2006f on aw_ccu0
> aw_mmcclk0:  mem 0x1c20088-0x1c2clk1:  Clock> mem 0x1c2008c-0x1c2008f on aw_ccu0
> aw_mmcclk2:  mem 0x1c20090-0x1c20093 on aw_ccu0
> aw_cpusclk0:  mem 0x1f01400-0x1f01403 on aw_ccu0
> clk_fixed4:  on aw_ccu0
> aw_apbclk2:  mem 0x1f0140c-0x1f0140f on aw_ccu0
> aw_gate1:  mem 0x1f01428-0x1f0142b on aw_ccu0
> aw_pll1:  mem 0x1c20044-0x1c20047 on aw_ccu0
> aw_usbclk0:  mem 0x1c200cc-0x1c200cf on aw_ccu0
> clk_fixed5:  mem 0x1c00030-0x1c00033 on aw_ccu0
> simplebus0:  on ofwbus0
> aw_reset0:  mem 0x1c202c0-0x1c202cb on simplebus0
> aw_reset1:  mem 0x1c202d0-0x1c202d3 on simplebus0
> aw_reset2:  mem 0x1c202d8-0x1c202db on simplebus0
> aw_reset3:  mem 0x1f014b0-0x1f014b3 on simplebus0
> iichb0:  mem 0x1c2ac00-0x1c2afff on 
> simplebus0
> iicbus0: hb0
> iichb1:  mem 0x1c2b000-0x1c2b3ff on 
> simplebus0
> iicbus1:  on iichb1
> iichb2:  mem 0x1c2b400-0x1c2b7ff on 
> simplebus0
> iicbus2:  on iichb2
> regfix0:  on ofwbus0
> regfix1:  on ofwbus0
> regfix2:  on ofwbus0
> regfix3:  on ofwbus0
> regfix4:  on ofwbus0
> aw_sid0:  mem 0x1c14000-0x1c143ff on 
> simplebus0
> awusbphy0:  on simplebu,0x1c86000-0x1c87fff on simplebus0
> gic0: pn 0x20, arch 0x2, rev 0x1, implementer 0x43b irqs 224
> gpio0:  mem 0x1c20800-0x1c20bff on 
> simplebus0
> gpiobus0:  on gpio0
> gpio1:  mem 0x1f02c00-0x1f02fff on 
> simplebus0
> gpiobus1:  on gpio1
> aw_nmi0:  mem 0x1f00c0c-0x1f00c43 on simplebus0
> generic_timer0:  on ofwbus0
> Timecounter "cy 2400 Hz quality 1000
> Event timer "ARM MPCore Eventtimer" frequency 2400 Hz quality 1000
> cpulist0:  on ofwbus0
> cpu0:  on cpulist0
> cpu1:  on cpulist0
> cpu2:  on cpulist0
> cpu3:  on cpulist0
> cpu4:  on cpulist0
> cpu5:  on cpulist0
> cpu6:  on cpulist0
> cpu7:  on cpulist0
> a10_mmc0:  mem 0x1c0f000-0x1c0 on 
> simplebus0
> mmc0:  on a10_mmc0
> a10_mmc1:  mem 0x1c11000-0x1c11fff on 
> simplebus0
> mmc1:  on a10_mmc1
> gpioc0:  on gpio0
> aw_wdog0:  mem 0x1c20ca0-0x1c20cbf on simplebus0
> uart0:  mem 0x1c28000-0x1c283ff on 
> simplebus0
> uart0: console (480769,n,8,1)
> gpioc1:  on gpio1
> iichb3:  mem 0x1f03400-0x1f037ff on simplebus0
> iicbus3:  on iichb3
> iic0:  on iicbus3
> axp81x_pmu0:  at addr 0x746 on iicbus3
> gpiobus2:  on axp81x_pmu0
> gpioled0:  at pin 0 on gpiobus2
> gpioled1:  at pin 1 on gpiobus2
> gpioc2:  on axp81x_pmu0
> iic1:  on iicbus0
> iic2:  on 

Re: boot0cfg on does not set default selection on gmirror device

[Patrick M. Hausen]

Hi, all,

> Am 24.10.2016 um 04:50 schrieb Ian Smith :
> 
> On Sun, 23 Oct 2016 15:53:59 +0200, Patrick M. Hausen wrote:
> 
>> Actual reboot of this production machine in two weeks when we run our
>> regular updates. But I expect that to "just work".
> 
> Warner expected the existing boot0cfg code to "just work" too.  And it 
> does, except that the upgrades to it failed to include a method to fix 
> existing installations retrospectively!

If the boot0 code 2.0 was severely broken, don't you think we would
have noticed? ;-)

One more thing, I just checked: the machines for which it did work
all the time are indeed younger and all have the 2.0 bootcode.

Thanks for your help.
Patrick
-- 
punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
i...@punkt.de   http://www.punkt.de
Gf: Jürgen Egeling  AG Mannheim 108285

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"