There is a bug in sbin/dhclient.c for large expiry values on 32 bit platforms
where time_t is a uint32_t (bug #218980,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218980). It is caused by a
compiler optimisation that removes an if-statement. The code below shows the
following output, clea
On Tue, May 02, 2017 at 10:26:17AM +0200, Nick Hibma wrote:
> There is a bug in sbin/dhclient.c for large expiry values on 32 bit platforms
> where time_t is a uint32_t (bug #218980,
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218980). It is caused by a
> compiler optimisation that remov
>> Should this be reported to the clang folks? Or is this to be expected when
>> abusing integer overflows this way?
>
> You will get an answer that this is expected. Add -fwrapv compiler flag
> to make signed arithmetic behave in a way different from the mine-field,
> or remove the code. For ke
On 2017-Apr-30, at 10:15 AM, Mark Millard wrote:
> On 2017-Apr-30, at 9:40 AM, Andrew Turner wrote:
>
>>> On 30 Apr 2017, at 12:02, Mark Millard wrote:
>>> . . .
>>
>> No, the device tree blob comes from UEFI. It seems the current UEFI only
>> provides the ACPI tables, and not a DTB.
>
> So
On 2017-May-2, at 2:53 AM, Mark Millard wrote:
> On 2017-Apr-30, at 10:15 AM, Mark Millard wrote:
>
>> On 2017-Apr-30, at 9:40 AM, Andrew Turner wrote:
>>
On 30 Apr 2017, at 12:02, Mark Millard wrote:
. . .
>>>
>>> No, the device tree blob comes from UEFI. It seems the current UEF
On 2017-May-2, at 3:37 AM, Mark Millard wrote:
> On 2017-May-2, at 2:53 AM, Mark Millard wrote:
>
>> On 2017-Apr-30, at 10:15 AM, Mark Millard wrote:
>>
>>> On 2017-Apr-30, at 9:40 AM, Andrew Turner wrote:
>>>
> On 30 Apr 2017, at 12:02, Mark Millard wrote:
> . . .
No, t
On 05/01/2017 14:31, Adrian Chadd wrote:
There were lots of commits that could break things. :-)
Can you compile up some intermediary versions between 315141 and
r317559 to find which commit range broke things? That'll make chasing
it down much quicker!
Thanks!
FWIW I'm seeing this on the
Hi,
About a year ago, I did a clean install on my desktop. No problems.
I tried a clean install now, and it dies with:
gtpzfsboot: error 1 lba 32
error 1
gptzfsboot: error 1 lba 4294967288
gptzfsboot: error 1 lba 1
gptzfsboot: no ZFS pools located, can't boot
The pool is visible in the live CD,
It turns out that the bt's from the example panics are
repeatable for the pc and lr sequence involved (but not
the specific sp's and fp's involved). I report this in
case it suggests anything. I'll note that the build had
a production style kernel for a build of -r317015 .
The first type of panic
On 2017-May-2, at 2:22 PM, Mark Millard wrote:
> It turns out that the bt's from the example panics are
> repeatable for the pc and lr sequence involved (but not
> the specific sp's and fp's involved). I report this in
> case it suggests anything. I'll note that the build had
> a production style
On 2017-May-2, at 2:30 PM, Mark Millard wrote:
> On 2017-May-2, at 2:22 PM, Mark Millard wrote:
>
>> It turns out that the bt's from the example panics are
>> repeatable for the pc and lr sequence involved (but not
>> the specific sp's and fp's involved). I report this in
>> case it suggests a
On 2017-May-2, at 2:59 PM, Mark Millard wrote:
> The code around handle_el1h_sync+0x70 :
>
> 00607804 sub sp, sp, #0x80
> 00607808 sub sp, sp, #0x120
> 0060780c stp x29, x30, [sp,#272]
> 00607810 stpx28, x29, [sp,#256]
> 00607814 stp
FYI: differences in FreeBSD's code vs.:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/BABJDBHI.html
and its "Example 11.5. Cleaning by Virtual Address". . .
(I do not claim to know that the differences
point to any error. But I note them in case
they prompt something. A c
13 matches
Mail list logo
