Searched hist:294685 (Results 1 - 2 of 2) sorted by relevance
| /freebsd-10.3-release/sys/boot/uboot/lib/ | ||
| H A D | copy.c | diff 294685 Sun Jan 24 22:02:22 MST 2016 ian MFC r293053, r293061, r293063, r293064, r293065, r293775, r293792: Use 64-bit math when finding a block of ram to hold the kernel. This fixes a problem on 32-bit systems which have ram occupying the end of the physical address space -- for example, a block of ram at 0x80000000 with a size of 0x80000000 was overflowing 32 bit math and ending up with a calculated size of zero. Use 64-bit math when processing the lists of physical and excluded memory to generate the phys_avail and dump_avail arrays. Work around problems that happen when there is ram at the end of the physical address space. Cast pointer through uintptr_t on the way to uint64_t to squelch a warning. Reword the comment to better describe what I found while researching the problem that led to this temporary workaround (and also so I can properly cite the PR in the commit this time). Cast using uintfptr_t and eliminate the cast to uint64_t which is uneeded because rounding down cannot increase the number of bits needed to express the result. Go back to using uintptr_t, because code that actually compiles is infinitely less buggy than code that is theoretically correct in some alternate universe. PR: 201614 |
| /freebsd-10.3-release/sys/arm/arm/ | ||
| H A D | physmem.c | diff 294685 Sun Jan 24 22:02:22 MST 2016 ian MFC r293053, r293061, r293063, r293064, r293065, r293775, r293792: Use 64-bit math when finding a block of ram to hold the kernel. This fixes a problem on 32-bit systems which have ram occupying the end of the physical address space -- for example, a block of ram at 0x80000000 with a size of 0x80000000 was overflowing 32 bit math and ending up with a calculated size of zero. Use 64-bit math when processing the lists of physical and excluded memory to generate the phys_avail and dump_avail arrays. Work around problems that happen when there is ram at the end of the physical address space. Cast pointer through uintptr_t on the way to uint64_t to squelch a warning. Reword the comment to better describe what I found while researching the problem that led to this temporary workaround (and also so I can properly cite the PR in the commit this time). Cast using uintfptr_t and eliminate the cast to uint64_t which is uneeded because rounding down cannot increase the number of bits needed to express the result. Go back to using uintptr_t, because code that actually compiles is infinitely less buggy than code that is theoretically correct in some alternate universe. PR: 201614 |
Completed in 57 milliseconds