Page MenuHomeFreeBSD

markmi_dsl-only.net (Mark Millard)
User

Projects

User does not belong to any projects.

User Details

User Since
Nov 19 2016, 6:23 AM (256 w, 1 d)

Recent Activity

Tue, Sep 28

markmi_dsl-only.net added a comment to D25219: ACPI: add support for (inherited) _DMA limits.

Looks to me like limits.lowaddr is still one too large, and so identifying the start of the wrong page instead of the end of the correct page by the code's overall criteria. As I remember, I still use limits.lowaddr-1 where I originally indicated in order to have the RPi4B have huge copy-then-diff operations work. (Though I've not been directly testing that for some time. It has been almost a year since I added the "-1" notes.)

Tue, Sep 28, 12:51 AM · arm64

Jul 29 2021

markmi_dsl-only.net abandoned D23376: Avoid having PowerMacs ending up with stuck-sleeping threads: force some boot-time TB value relationships across sockets/cores..

I no longer have access to any operational old-PowerMacs. (And never had access to any other example types of PowerPC/Power hardware.) As such, I'll no longer be involved in powerpc64 or 32-bit powerpc activities.

Jul 29 2021, 7:13 AM · PowerPC

Apr 11 2021

markmi_dsl-only.net added a comment to D18658: top: fix PID sorting after r340742; add process birth time sorting.

Thanks for the patch, even if FreeBSD did not adopt it.

Apr 11 2021, 9:58 PM

Mar 13 2021

markmi_dsl-only.net added inline comments to D29136: WIP: [PowerPC] PowerMac timebase sync for G4.
Mar 13 2021, 6:57 AM · PowerPC

Mar 12 2021

markmi_dsl-only.net added inline comments to D29136: WIP: [PowerPC] PowerMac timebase sync for G4.
Mar 12 2021, 12:19 AM · PowerPC

Mar 11 2021

markmi_dsl-only.net added inline comments to D29136: WIP: [PowerPC] PowerMac timebase sync for G4.
Mar 11 2021, 9:00 PM · PowerPC

Mar 9 2021

markmi_dsl-only.net added a comment to D29136: WIP: [PowerPC] PowerMac timebase sync for G4.

FYI: G5 2-sockets/2-cores-each basic info follows.

Mar 9 2021, 4:57 AM · PowerPC
markmi_dsl-only.net added a comment to D29136: WIP: [PowerPC] PowerMac timebase sync for G4.

I'll remind of the old issue that the pre-exisiting code's use of platform_smp_timebase_sync does
not follow a synchronize everything at once protocol everywhere, sometimes using the ap
argument being 1 without any matching ap being 0. This invalidated one of jhibbits patches in
the past. (I'm writing from vague memory here. So be careful from reading too much detail.)

Mar 9 2021, 2:45 AM · PowerPC
markmi_dsl-only.net added a comment to D29136: WIP: [PowerPC] PowerMac timebase sync for G4.

In case it helps for some G4 dual socket contexts (captured while the machine happens
to be up and accessible). Turns out each of the cpus has a timebase-enable listed, but
they are numerically equal on the machine in question.

Mar 9 2021, 1:58 AM · PowerPC

Feb 16 2021

markmi_dsl-only.net added a comment to D28696: linux: Unmap the VDSO page when unloading.

https://ci.freebsd.org/job/FreeBSD-main-i386-build/19172/console shows:

Feb 16 2021, 9:52 PM

Feb 14 2021

markmi_dsl-only.net added a comment to D23376: Avoid having PowerMacs ending up with stuck-sleeping threads: force some boot-time TB value relationships across sockets/cores..

FYI: Both of the "PowerMac11,2 with 2 sockets, 2 cores each" have died of cooling system failures. (I can sometimes boot one, but it is problematical to do much with without overheating.) So, now the only G5 I now have access to for general testing is a "2 socket/1-core-each PowerMac7,2" . I still have access to the two PowerMac3,6 with "2 sockets, 1 core each" G4 examples. (But there are other major FreeBSD kernel issues for 32-bit PowerMacs, even for single socket ones: it gradually clears some user-process pages to zero.)

Feb 14 2021, 7:29 PM · PowerPC

Feb 4 2021

markmi_dsl-only.net added inline comments to D28159: opencrypto: Fix assignment of crypto completions to worker threads.
Feb 4 2021, 10:03 AM

Jan 3 2021

markmi_dsl-only.net added a comment to D27420: loader: implement framebuffer console.

This made the only amd64 FreeBSD system that I have access to display a blank
screen in the loader. It is a ThreadRipper 1950X system.

Jan 3 2021, 5:13 AM

Oct 20 2020

markmi_dsl-only.net added a comment to D26853: RPI4: enable USB-boot for the 8GB-model etc.

For your side note: A comparison/contrast. Your linked material shows:

pcib0: <BCM2838-compatible PCI-express controller> mem 0x7d500000-0x7d50930f irq 70,71 on simplebus2
pcib0: hardware identifies as revision 0x304.
pci1: <PCI bus> on pcib0
pcib1: <PCI-PCI bridge> irq 81 at device 0.0 on pci1
pci2: <PCI bus> on pcib1
bcm_xhci0: <VL805 USB 3.0 controller (on the Raspberry Pi 4b)> irq 82 at device 0.0 on pci2
bcm_xhci0: 32 bytes context size, 64-bit DMA
usbus0 on bcm_xhci0
pci0: <PCI bus> on pcib0
pci0: failed to allocate bus number
device_attach: pci0 attach returned 6

But what I get from my boot (indirectly via a microsd card and use of modern released-firmware's .dtb) is:

pcib0: <BCM2838-compatible PCI-express controller> mem 0x7d500000-0x7d50930f irq 70,71 on simplebus2
pcib0: hardware identifies as revision 0x304.
pci0: <PCI bus> on pcib0
pcib1: <PCI-PCI bridge> irq 81 at device 0.0 on pci0
pci1: <PCI bus> on pcib1
bcm_xhci0: <VL805 USB 3.0 controller (on the Raspberry Pi 4b)> irq 82 at device 0.0 on pci1
bcm_xhci0: 32 bytes context size, 64-bit DMA
usbus0 on bcm_xhci0

So the first differences are:
Your context: "pci1: <PCI bus> on pcib0" (no pci0 shown at this stage)
My context has instead: "pci0: <PCI bus> on pcib0"

Oct 20 2020, 7:15 AM
markmi_dsl-only.net added a comment to D26853: RPI4: enable USB-boot for the 8GB-model etc.

Ahh, gradual understanding on my part. Thanks.

Oct 20 2020, 3:36 AM

Oct 19 2020

markmi_dsl-only.net added a comment to D26853: RPI4: enable USB-boot for the 8GB-model etc.

But the FreeBSD kernel does need to deal with the VL805-firmware issue in that context and does so without the .dtb file change.
So why would u-boot need the change when the kernel does not? (Again: out of my depth here.) Are you saying that the FreeBSD kernell is doing something wrong >currently and needs to be fixed once the .dtb adjustment is in place?

the DeviceTree is loaded before u-boot(and the kernel) , so in this case it can trigger the firmware-load.
It's an RPI4 hardware quirk on newer board-revisions.

Oct 19 2020, 9:16 PM
markmi_dsl-only.net added a comment to D26853: RPI4: enable USB-boot for the 8GB-model etc.
reset = "/soc/firmware/reset";

. . .

https://github.com/u-boot/u-boot/commit/f676eb217bdff3bd734a42c8f9bbc58c9100055c

on newer board revisions a dedicated chip which holded the VL805-firmware was removed,
so u-boot needs to be instructed to reset the controller to load the firmware from the VideoCore in a very early stage(before the OS itself
initializes the driver).that early stage is when bcm2711-rpi-4-b.dtb is loaded.

. . .

of course u-boot wouldn`t' need an early stage xhci-reset when it boots from an SD-card

Oct 19 2020, 7:01 PM
markmi_dsl-only.net added a comment to D26853: RPI4: enable USB-boot for the 8GB-model etc.

Ignoring what appears to be general, systematic phandle and phy-handle numbering differences, the following appears to be what this has changed vs. a fairly modern firmware's .dtb file. I'll start with the completely new additions it made:

Oct 19 2020, 11:16 AM

Oct 11 2020

markmi_dsl-only.net added inline comments to D26344: bcm2838_pci.c: Respect DMA limits of controller..
Oct 11 2020, 7:14 PM

Oct 7 2020

markmi_dsl-only.net added inline comments to D26344: bcm2838_pci.c: Respect DMA limits of controller..
Oct 7 2020, 5:59 PM
markmi_dsl-only.net added inline comments to D25219: ACPI: add support for (inherited) _DMA limits.
Oct 7 2020, 5:41 PM · arm64
markmi_dsl-only.net added inline comments to D25219: ACPI: add support for (inherited) _DMA limits.
Oct 7 2020, 7:09 AM · arm64

Sep 29 2020

markmi_dsl-only.net added a comment to D25219: ACPI: add support for (inherited) _DMA limits.

May be the following notes will be useful to someone with an appropriate background . . .

Sep 29 2020, 8:38 PM · arm64

Sep 28 2020

markmi_dsl-only.net added inline comments to D25219: ACPI: add support for (inherited) _DMA limits.
Sep 28 2020, 4:02 AM · arm64

Sep 26 2020

markmi_dsl-only.net added inline comments to D25219: ACPI: add support for (inherited) _DMA limits.
Sep 26 2020, 3:45 PM · arm64
markmi_dsl-only.net added inline comments to D25219: ACPI: add support for (inherited) _DMA limits.
Sep 26 2020, 3:55 AM · arm64

Sep 25 2020

markmi_dsl-only.net added a comment to D25219: ACPI: add support for (inherited) _DMA limits.

I've tested head -r363932 under uefi/ACPI v1.20 with the 3072 limit disabled and it failed the huge-file duplicate and diff/cmp test:

# cp -aRx /usr/obj/clang-armv7-on-aarch64.tar /usr/obj/clang-armv7-on-aarch64.alt_tar
# diff /usr/obj/clang-armv7-on-aarch64.tar /usr/obj/clang-armv7-on-aarch64.alt_tar
Binary files /usr/obj/clang-armv7-on-aarch64.tar and /usr/obj/clang-armv7-on-aarch64.alt_tar differ
# cmp -l /usr/obj/clang-armv7-on-aarch64.tar /usr/obj/clang-armv7-on-aarch64.alt_tar | head -30
2633269249   3   0
2633269251   3   0
2633269252  55   0
2633269253   6   0
2633269254  21   0
2633269255 227   0
2633269256   1   0
2633269257 135   0
2633269258 336   0
2633269259  22 140
2633269260   0 100
2633269261 346   0
2633269262 353   0
2633269265 227   0
2633269266   1 160
2633269267 170 140
2633269268 336 100
2633269269  22   0
2633269271 362   0
2633269272 353   0
2633269275 227   0
2633269276   1   0
2633269277 225   0
2633269278 336   0
2633269279  22   0
2633269281 376   0
2633269282 353   1
2633269285   0   1
2633269289   0 223
2633269290   0 321

For reference:

# ls -ldT /usr/obj/clang-armv7-on-aarch64*
-rw-r--r--  1 root  wheel  11570948096 Jul 18 18:32:37 2020 /usr/obj/clang-armv7-on-aarch64.alt_tar
-rw-r--r--  1 root  wheel  11570948096 Jul 18 18:32:37 2020 /usr/obj/clang-armv7-on-aarch64.tar

(So the over 10 GiByte original file is significantly larger than the 8 GiByte RAM, although I've had large but much smaller files fail as well.)

Sep 25 2020, 8:56 AM · arm64

Sep 24 2020

markmi_dsl-only.net added a comment to D26344: bcm2838_pci.c: Respect DMA limits of controller..

As I have just reported on the arm list, the checked-in patch fails the huge file duplicate and diff/cmp test. xhci
DMA is still a problem.

Sep 24 2020, 7:07 PM

Sep 10 2020

markmi_dsl-only.net added a comment to D26344: bcm2838_pci.c: Respect DMA limits of controller..

Given what I've seen about the 5.8 mainline Linux kernel status for the RPi4 and that Fedora just branched 33 from Rawhide (for a late Oct. release), I decided to try installing a Fedora 33 branch server and UEFI/ACPI v1.20 and doing a "yum update" on the booted result. (USB3 SSD based, no microsd card involved.) That ended up with a 5.8.7-300.fc33.aarch64 kernel and it sees all 8GiB of RAM. I've tried the huge file copy and diff type of test and it has not failed yet. (The files are each bigger than the RAM.) (I've not noticed other issues but that likely does not imply much.) For reference, the boot reported the following "Zone ranges":

[    0.000000] NUMA: Faking a node at [mem 0x0000000000000000-0x00000001ffffffff]
[    0.000000] NUMA: NODE_DATA [mem 0x1fefec8c0-0x1ff002fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000000000-0x000000003fffffff]
[    0.000000]   DMA32    [mem 0x0000000040000000-0x00000000ffffffff]
[    0.000000]   Normal   [mem 0x0000000100000000-0x00000001ffffffff]
[    0.000000]   Device   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x00000000001fffff]
[    0.000000]   node   0: [mem 0x0000000000200000-0x00000000337d7fff]
[    0.000000]   node   0: [mem 0x00000000337d8000-0x000000003387ffff]
[    0.000000]   node   0: [mem 0x0000000033880000-0x000000003390ffff]
[    0.000000]   node   0: [mem 0x0000000033910000-0x000000003398ffff]
[    0.000000]   node   0: [mem 0x0000000033990000-0x00000000339affff]
[    0.000000]   node   0: [mem 0x00000000339b0000-0x0000000033a2ffff]
[    0.000000]   node   0: [mem 0x0000000033a30000-0x0000000036efffff]
[    0.000000]   node   0: [mem 0x0000000036f00000-0x00000000372dffff]
[    0.000000]   node   0: [mem 0x00000000372e0000-0x000000003b2fffff]
[    0.000000]   node   0: [mem 0x0000000040000000-0x00000000fbffffff]
[    0.000000]   node   0: [mem 0x0000000100000000-0x00000001ffffffff]
[    0.000000] Zeroed struct page in unavailable ranges: 552 pages
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000001ffffffff]

What OpenBSD did for the size of the DMA area for XHCI looks to be unusual (relative to NetBSD and Linux). But the next-to-last "node 0:" line above does show not using the whole DMA32 range. (I do not now why they had it do that.)

Sep 10 2020, 7:08 AM

Sep 9 2020

markmi_dsl-only.net added inline comments to D26344: bcm2838_pci.c: Respect DMA limits of controller..
Sep 9 2020, 9:13 PM
markmi_dsl-only.net added a comment to D26344: bcm2838_pci.c: Respect DMA limits of controller..

FYI: Something that I do not see represented in the NetBSD debug information is that DMA channel 11 (of DMA4 engine type) is the only one explicitly noted in rpi_DATA_2711_1p0.pdf as "additionally able to access the PCIe interface".

Sep 9 2020, 6:03 AM
markmi_dsl-only.net added a comment to D26344: bcm2838_pci.c: Respect DMA limits of controller..

. . .

The 0x3c000000 limit is taken from OpenBSD.

Sep 9 2020, 3:21 AM

Sep 7 2020

markmi_dsl-only.net added a comment to D26344: bcm2838_pci.c: Respect DMA limits of controller..

My understanding is that different devices have different DMA limits. XHCI has 3 GiB but others have 1 GiB. There is not one DMA controller enforcing one limit common to all contexts but multiple separate limits. Using the smallest limit for all devices may well be an alternative but that is not what the ACPI tables describe (from what I read on the lists).

Sep 7 2020, 8:34 PM

Jul 11 2020

markmi_dsl-only.net added a comment to D25068: Add driver for bcm2838 PCI express controller.

This code leads to an OverDrive 1000 getting the following error.

Jul 11 2020, 8:13 PM

Jun 20 2020

markmi_dsl-only.net added inline comments to D23828: powerpc/powermac: Constrain 'cpu_sleep()' for AIM to mpc745x.
Jun 20 2020, 12:21 AM

Feb 28 2020

markmi_dsl-only.net added a comment to D15955: Discover cards on boot.

I have removed my prior comments: they traced to a different issue that, when worked around, got rid of the behavior that I had reported. Sorry for the noise.

Feb 28 2020, 7:21 PM

Feb 23 2020

markmi_dsl-only.net added a comment to D23376: Avoid having PowerMacs ending up with stuck-sleeping threads: force some boot-time TB value relationships across sockets/cores..

. . .
You can look in Linux's arch/powerpc/platform/powermac/smp.c, and arch/powerpc/kernel/smp-tbsync.c for how Linux does it. Their generic tbsync handshake is similar to yours.

Feb 23 2020, 9:25 PM · PowerPC
markmi_dsl-only.net added a comment to D23376: Avoid having PowerMacs ending up with stuck-sleeping threads: force some boot-time TB value relationships across sockets/cores..

. . .
I do intend to shortly (next few days) clean up the one additional platform_timebase_sync() user (cpu_sleep()) to not use it, and handle it directly, since the code in cpu_sleep() is actually mpc74xx-specific, it's not generic at all. So once that's made explicit, a proper rendezvous sync should be done in platform_powermac.c instead.
. . .

Feb 23 2020, 4:29 AM · PowerPC
markmi_dsl-only.net added inline comments to D23376: Avoid having PowerMacs ending up with stuck-sleeping threads: force some boot-time TB value relationships across sockets/cores..
Feb 23 2020, 12:40 AM · PowerPC

Feb 22 2020

markmi_dsl-only.net added inline comments to D23376: Avoid having PowerMacs ending up with stuck-sleeping threads: force some boot-time TB value relationships across sockets/cores..
Feb 22 2020, 10:56 PM · PowerPC
markmi_dsl-only.net added inline comments to D23376: Avoid having PowerMacs ending up with stuck-sleeping threads: force some boot-time TB value relationships across sockets/cores..
Feb 22 2020, 10:20 PM · PowerPC
markmi_dsl-only.net added a comment to D23376: Avoid having PowerMacs ending up with stuck-sleeping threads: force some boot-time TB value relationships across sockets/cores..

What we really want to achieve is a better timebase sync mechanism. This can only be achieved by disabling the timebase, rendezvousing, and re-enabling it. Adding a drift into the generic code for a specific platform is not the correct solution.

Feb 22 2020, 9:30 PM · PowerPC
markmi_dsl-only.net added inline comments to D23376: Avoid having PowerMacs ending up with stuck-sleeping threads: force some boot-time TB value relationships across sockets/cores..
Feb 22 2020, 6:35 PM · PowerPC

Feb 17 2020

markmi_dsl-only.net added a comment to D23729: powerpc: unconditionally mark SLB zones UMA_ZONE_CONTIG.

. . .> Ah, that clarifies things. I was looking for a problem in r357548.

Feb 17 2020, 9:30 PM
markmi_dsl-only.net added a comment to D23729: powerpc: unconditionally mark SLB zones UMA_ZONE_CONTIG.

Can you explain why this makes a difference, at least for slbt_zone? I think I am missing something.

Feb 17 2020, 7:10 PM

Feb 2 2020

markmi_dsl-only.net added a comment to D15955: Discover cards on boot.
Feb 2 2020, 4:39 AM

Feb 1 2020

markmi_dsl-only.net added a comment to D15955: Discover cards on boot.
Feb 1 2020, 10:59 PM

Jan 30 2020

markmi_dsl-only.net added inline comments to D23376: Avoid having PowerMacs ending up with stuck-sleeping threads: force some boot-time TB value relationships across sockets/cores..
Jan 30 2020, 7:44 PM · PowerPC
markmi_dsl-only.net added inline comments to D23376: Avoid having PowerMacs ending up with stuck-sleeping threads: force some boot-time TB value relationships across sockets/cores..
Jan 30 2020, 6:07 PM · PowerPC
markmi_dsl-only.net added a comment to D23376: Avoid having PowerMacs ending up with stuck-sleeping threads: force some boot-time TB value relationships across sockets/cores..

Yeah, I used to see this too (on either power9 or amigaone x5000, can't remember which.) IIRC, the problem is that if the tb is significantly unsynced, the callwheel algorithm falls over and misses wakeups for things.

Jan 30 2020, 5:37 PM · PowerPC

Jan 29 2020

markmi_dsl-only.net added a comment to D23376: Avoid having PowerMacs ending up with stuck-sleeping threads: force some boot-time TB value relationships across sockets/cores..

If there are non-PowerMac powerpc platforms that get the threads-stuck-sleeping
problem, then this type of solution may be insufficient for it to generalize for the specific
problem. For example, it is not obvious how accurate such would end up for a context
where NUMA can be relevant. I do not have a context for investigating anything that
modern.

Jan 29 2020, 6:36 AM · PowerPC

Jan 26 2020

markmi_dsl-only.net added a comment to D23376: Avoid having PowerMacs ending up with stuck-sleeping threads: force some boot-time TB value relationships across sockets/cores..

Note: I was not (and am not) style(9) literate when I did the investigation that eventually stabilized on this code. My information-handling capacity was limited. I fully expect this will need to be dealt with at some point. But I'd prefer to first have the technique(s) used be thought to be stable before focusing on the other type of knowledge.

Jan 26 2020, 11:13 PM · PowerPC
markmi_dsl-only.net created D23376: Avoid having PowerMacs ending up with stuck-sleeping threads: force some boot-time TB value relationships across sockets/cores..
Jan 26 2020, 11:04 PM · PowerPC

Jul 10 2019

markmi_dsl-only.net updated subscribers of D20598: powerpc: Transition to Secure-PLT, like most other OSs.

FYI: The addition to CFLAGS.powerpc did not add -msecure-plt to the cc for linking libc.so.7.full :

Jul 10 2019, 1:44 AM
markmi_dsl-only.net added a comment to D20598: powerpc: Transition to Secure-PLT, like most other OSs.

Using -msecure-plt did no good with system-clang. Despite the -msecure-plt as shown below:

Jul 10 2019, 12:58 AM

Jul 9 2019

markmi_dsl-only.net added a comment to D20598: powerpc: Transition to Secure-PLT, like most other OSs.

FYI: I was using devel/powerpc64-binutils with system clang (8.0.0 or now 8.0.1), not gcc.
Changes to gcc will not change the behavior for what I was doing.

Jul 9 2019, 5:34 PM
markmi_dsl-only.net added a comment to D20598: powerpc: Transition to Secure-PLT, like most other OSs.

Justin wrote "Secure-PLT is fully compatible with BSS-PLT, so there's no issue with compatibility".

Jul 9 2019, 6:57 AM

Apr 25 2019

markmi_dsl-only.net added a comment to D18658: top: fix PID sorting after r340742; add process birth time sorting.

In order to keep the thread order stable for process-birth-time,
I ended up also using:

Apr 25 2019, 10:54 AM

Mar 24 2019

markmi_dsl-only.net added a comment to D19588: Add a new efi-update-loader script and associated man page.

I frequently cross-build amd64->aarch64 and amd64->armv7 and also do
installworld's of the aarch64 and armv7 worlds into directories trees on the
amd64 machine ( same file system as the amd64 world is on, but in something
like, for example, /usr/obj/DESTDIRs/clang-cortexA53-installworld-poud ).
(Later such are used via qemu-user-static and poudriere-devel , for example.)

Mar 24 2019, 8:08 AM

Mar 3 2019

markmi_dsl-only.net added a comment to D18547: Fix llvm-tblgen self-bootstrap.

FYI: In attempting a devel/powerpc64-xtoolchain-gcc based build of head -r334018
on a powerpc64 I just had to make these two changes in order to avoid the problem
reported here: otherwise unable to build llvm-tblgen .

Mar 3 2019, 9:34 AM

Jan 25 2019

markmi_dsl-only.net added a comment to D17930: clang: default to DWARF 4 as of FreeBSD 12.

What of using libexec/gdb ? WITH_GDB is still the default except on aarch64 and riscv64* .

libexec/gdb is only intended for crashinfo(8) and the kernel is built with an explicit -gdwarf2 flag so will not be affected by this change. In any case libexec/gdb is probably going away in 13.0 (@jhb can comment).

Jan 25 2019, 8:54 PM

Jan 13 2019

markmi_dsl-only.net added a comment to D17930: clang: default to DWARF 4 as of FreeBSD 12.

What of using libexec/gdb ? WITH_GDB is still the default except on aarch64 and riscv64* . There are architectures for which modern gdb from ports fails ( by running into bugs in C++ thrown-exception support in the system libgc_s ): powerpc families. (I experiment with using more modern compilers. clang has issues of its own but devel/powerpc64-gcc for powerpc64 targeting is useful for buildworld buildkernel and more. I have a patched libgcc_s that I reported on the lists but most folks do not have.)

Jan 13 2019, 7:49 AM

Jul 4 2017

markmi_dsl-only.net added a comment to D11475: Zero initialize all fields of socket structure.

This change addresses the direct, observed consequences for switching from
the first anonymous struct to the second one: it avoids interpreting old
"first struct" material as upcall information.

Jul 4 2017, 9:15 AM

Jul 1 2017

markmi_dsl-only.net added a comment to D9770: Listening sockets revamp try #2..

Again for future reference for folks that might look at this:

Jul 1 2017, 4:17 PM
markmi_dsl-only.net added a comment to D9770: Listening sockets revamp try #2..

In essence some notes from bugzilla 220404 for
future reference to folks that might look here.

Jul 1 2017, 2:30 AM

Jun 28 2017

markmi_dsl-only.net added a comment to rS317835: arch(7): add a table of per-arch initial/final FreeBSD version.

If this page or a variant is to be used for 11.1 then
pc98 should be covered rather than only being listed
for the initial/final releases. (I'm less sure for history
like alpha or ia64.)

Jun 28 2017, 9:23 PM

Apr 28 2017

markmi_dsl-only.net added a comment to D10537: Make sure <arch-gcc> come with consistent content.

I should note that when devel/*-binutils went to
2.28 which failed I reverted to devel/*binutils
-r436731 (2.27) in order for things to work. I still
have that configuration and it was used in the
test builds that I did.

Apr 28 2017, 9:29 PM
markmi_dsl-only.net added a comment to D10537: Make sure <arch-gcc> come with consistent content.

FYI: prior to this change a self-hosted/native build of
devel/aarch64-gcc or devel/powerpc64-gcc would
fail for not finding 6 files listed in pkg-plist .
devel/arm64-gcc did not list the 6 files there and so
did not install them but the self-hosted/native build
would complete.

Apr 28 2017, 7:51 PM
markmi_dsl-only.net accepted D10537: Make sure <arch-gcc> come with consistent content.

I built examples based on patching:

Apr 28 2017, 7:31 PM

Mar 6 2017

markmi_dsl-only.net added a comment to D9869: Return EINVAL for userland CCBs with CAM_UNLOCKED set.

-r314624 prevented a PowerMac G5 so-called "Quad Core" from competing
its boot (of -r314687): CAM status: Command timeout's. Reverting the two
files fixed it. See, e.g.,

Mar 6 2017, 10:49 AM

Feb 17 2017

markmi_dsl-only.net added a comment to D9593: Load the new sp_el0 with interrupts disabled in fork_trampoline.

Note: The "truncated" sp/fp line for "panic() at . . ."
is from the serial console tending to drop text.

Feb 17 2017, 10:23 PM
markmi_dsl-only.net added a comment to D9593: Load the new sp_el0 with interrupts disabled in fork_trampoline.

I got a panic that involved fork_trampoline in the back trace.
I've no clue if it is related.

Feb 17 2017, 9:59 PM

Feb 15 2017

markmi_dsl-only.net added a comment to D9593: Load the new sp_el0 with interrupts disabled in fork_trampoline.

That last buildworld buildkernel completed just
fine (really only building the kernel since world
had completed before).

Feb 15 2017, 3:02 AM
markmi_dsl-only.net added a comment to D9593: Load the new sp_el0 with interrupts disabled in fork_trampoline.

The core files did not suggest a stack corruption
to me, nor was fork active. My test code
recorded its before and after fork stack address
examples and they were equal as they should be.

Feb 15 2017, 2:06 AM

Feb 14 2017

markmi_dsl-only.net added a comment to D9593: Load the new sp_el0 with interrupts disabled in fork_trampoline.

Drat: buildworld got a different failure in sh (see below).

Feb 14 2017, 11:05 PM
markmi_dsl-only.net added a comment to D9593: Load the new sp_el0 with interrupts disabled in fork_trampoline.

Test status update at ~3 hours 40 minutes in:

Feb 14 2017, 9:17 PM
markmi_dsl-only.net added a comment to D9593: Load the new sp_el0 with interrupts disabled in fork_trampoline.

One minor point:

Feb 14 2017, 5:17 PM