mattst88 - Network

The voltage in the leg carried by the flaming-hot wire fluctuated significantly throughout the day and also drops measurably over the course...

The voltage in the leg carried by the flaming-hot wire fluctuated significantly throughout the day and also drops measurably over the course of the day. I assume that indicates increasing resistance in the wire as it heats up.

With the new transformer, both legs' voltages are stable.

Pretty sure this is the best bug report I've ever filed.

Afterwards I checked my #HomeAssistant energy monitoring data (provided by an Emporia Vue 2 flashed with #ESPHome). The yellow line is the...

Afterwards I checked my #HomeAssistant energy monitoring data (provided by an Emporia Vue 2 flashed with #ESPHome). The yellow line is the voltage on one 120V leg from the transformer (the one that was going to burn up), and the blue line is the voltage on the other 120V leg.

The three sections of the graph are during the problem, while the power is out, and after the new transformer was installed.

The wire was still too hot to touch 10 minutes later. It had been so hot that the ceramic insulator separating it from the transformer...

The wire was still too hot to touch 10 minutes later. It had been so hot that the ceramic insulator separating it from the transformer housing had cracked. I assume the result, if not reported, would have been an electrical fire.

I was lucky that my lazyness in bypassing the UPS hadn't lead to some disaster...

I immediately called the power company and reported the issue, and then began turning off breakers in my electrical panel.A repair crew...

I immediately called the power company and reported the issue, and then began turning off breakers in my electrical panel.

A repair crew arrived about an hour later, and began by inspecting my meter. I showed them the thermal image and they immediately switched their attention to the transformer.

My neighbor and I watched them take down the old transformer and chatted with the lineman while he waited on a new one to arrive.

A couple of years ago, some electrical component on or near our transformer caught fire. The power company came and replaced it and things...

A couple of years ago, some electrical component on or near our transformer caught fire. The power company came and replaced it and things were fine.

But this made me wonder if we were headed for the same outcome.

I took my thermal camera out and pointed it at the transformer, and saw what I suspected was a problem...

The wire carrying one of the 120V legs was about 80°C (~180°F). (My neighbor's thermal camera reported 380°F!)

After work, we had dinner and were in the living room playing video games. As the sun set we turned on the lamps and noticed them flickering...

After work, we had dinner and were in the living room playing video games. As the sun set we turned on the lamps and noticed them flickering pretty badly.

I stuck a multimeter in the outlet and saw that the voltage was fluctuating a lot and would often drop below 100V (we have 120V circuits in the US).

Not good.

One morning recently, I got up and went downstairs. My wife told me that the UPS in the basement (powering my server) was making a bunch of...

One morning recently, I got up and went downstairs. My wife told me that the UPS in the basement (powering my server) was making a bunch of noise. I groaned and checked on it. It was indeed turning on and off a few times per minute and had been doing this for a few hours according to #HomeAssistant.

I ignored it and got ready for work. When I started work a bit later, I realized that the UPS in my home office was doing the same thing.

Stupidly I just bypassed the UPS and plugged into the wall.

Today's example:A few years ago the Xserver failed to build on SPARC. @thesamesam fixed it in...

Today's example:

A few years ago the Xserver failed to build on SPARC. @thesamesam fixed it in https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/813. The fix added a necessary bit of code to the build that had been missed in the autotools → meson transition.

Recently we discovered it had stopped compiling at some point when GCC became more strict! (Fix: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1751)

#sparc #xorg #xserver #gcc

@keithp has a saying:> There are two types of code: tested code and broken codeEarly in my career I thought "nah, there's some...

@keithp has a saying:

> There are two types of code: tested code and broken code

Early in my career I thought "nah, there's some code that just works and doesn't need maintenance".

But once again his adage proves true.

I landed some improvements and small optimizations to #pixman's AltiVec code. See...

I landed some improvements and small optimizations to #pixman's AltiVec code. See https://gitlab.freedesktop.org/pixman/pixman/-/merge_requests/136

It was fun working with a new (to me) instruction set and trying to figure out how to puzzle together the pieces into something that improved the `pix_multiply()` function (which is kind of the core primitive of most fast paths).

I couldn't figure out a way to use the `vec_mradds`/`vmhraddshs` instruction. Maybe you can? (see https://gitlab.freedesktop.org/pixman/pixman/-/merge_requests/136#note_2699795)

#altivec #powerpc #simd

I fixed an issue in pixman's Altivec code the other day --...

I fixed an issue in pixman's Altivec code the other day -- https://cgit.freedesktop.org/pixman/commit/?id=207626180d0282bb14a50f2e494174f54ac8a6ce

And in the process, I read through the Altivec docs and discovered that there are vector instructions that pack and unpack between a8r8g8b8 and a1r5g5b5 formats (but nothing fo r5g6b5).

Any clues why? Was a1r5g5b5 really common on Mac OS or something? I don't think I've seen a1r5g5b5 used anywhere.

#powerpc #altivec #simd #macos9 #pixman

People complain about AI chatbots performing customer support, etc., but I think most real humans I've interacted with via Facebook...

People complain about AI chatbots performing customer support, etc., but I think most real humans I've interacted with via Facebook Marketplace are measurably and significantly worse.

gcc-14 was unmasked in Gentoo recently, so I gave it a try.It works. No more failures. Whole system updated successfully. Some mysteries...

gcc-14 was unmasked in Gentoo recently, so I gave it a try.

It works. No more failures. Whole system updated successfully. Some mysteries aren't meant to be solved.

Single stepping in #gdb, I ultimately came across a longjmp() call (apparently libXt handles errors this way?), and it was this call that...

Single stepping in #gdb, I ultimately came across a longjmp() call (apparently libXt handles errors this way?), and it was this call that triggered the failure.

Turns out each of the subtests checks some exceptional case and expects a function call to fail by longjmp()'ing, but only the first unit test actually prepared for the jump with a call to setjmp().

As a result, when the second subtest triggered its own longjmp() it jumped to the first subtest's function that had already completed!

Another fun #debugging adventure, this time with a happy ending.A unit test in libXmu failed on x86-32...

Another fun #debugging adventure, this time with a happy ending.

A unit test in libXmu failed on x86-32 (https://gitlab.freedesktop.org/xorg/lib/libxmu/-/issues/2). I looked for the typical things first like bad casts but didn't see anything wrong.

I noticed that the unit test program runs two subtests and the log indicates that it completed the first successfully before crashing, but when I ran it under gdb the back trace showed it in the first unit test when the segfault occurred. Very strange.

Perhaps the most ridiculous thing is the simplicity of the test case — single line of C:> mattst88@cubox ~ $ cat wtf.c > double...

Perhaps the most ridiculous thing is the simplicity of the test case — single line of C:

> mattst88@cubox ~ $ cat wtf.c
> double wtf(void) { return 7.0; }
> mattst88@cubox ~ $ gcc -O2 -c wtf.c
> /tmp/ccYogZ0U.s: Assembler messages:
> /tmp/ccYogZ0U.s:24: Error: garbage following instruction -- `vmov.f64 d0,#6.:e+0'

So I think barring some breakthrough, the CuBox will be retired. It is painfully slow as it is.

I took a binary package of gcc built on my CuBox that reproduces the issue there, and I installed it in the 32-bit chroot on Gentoo's...

I took a binary package of gcc built on my CuBox that reproduces the issue there, and I installed it in the 32-bit chroot on Gentoo's aarch64 development system. The issue doesn't reproduce.

I took a binary package of gcc built in the 32-bit chroot on Gentoo's aarch64 development system that doesn't reproduce the issue there, and I installed it on the CuBox. The issue *does* reproduce.

So I don't know if there's just something wrong with the Marvell Armada 510 SoC in the CuBox or what.

I don't know!My best guess is that some floating-point imprecision is essentially resulting in some calculation producing 6 and 10/10...

I don't know!

My best guess is that some floating-point imprecision is essentially resulting in some calculation producing 6 and 10/10 instead of 7.0.

I've tried a ton of things to narrow this down. I tried rebuilding gmp, mpfr, and mpc which gcc uses for multiprecision arithmetic. I've tried different versions of gcc — and I've tried bisecting gcc. None of the gccs built for bisecting reproduce the issue. I tried testing gcc's stage1 build (--disable-bootstrap) as well as stages 2 and 3.

My best guess is that in gcc's `real_to_decimal_for_mode` function...

My best guess is that in gcc's `real_to_decimal_for_mode` function (https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/real.cc;h=2c682b1809d46c6957e1ce83ec808377c27f8b65;hb=HEAD#l1812), something goes wrong.

The code does the old trick of adding the character '0' an integer digit to produce the ASCII character representing the digit. E.g. '0' + 6 == '6'. '0' is ASCII 48, add 6 gives ASCII 54 which is the character '6'.

But something is wrong, and what is supposed to be a single digit is 10, and '0' + 10 == 58 which is ':'.

But what is going wrong to cause this?

I also tried and couldn't reproduce the failure in a 32-bit chroot on #Gentoo's #aarch64 development machine, so I was stuck doing...

I also tried and couldn't reproduce the failure in a 32-bit chroot on #Gentoo's #aarch64 development machine, so I was stuck doing all the debugging (and loooooong #gcc builds) on my very slow single-core 800MHz Solid Run #CuBox.

Diff'ing the assembly output between the non-working and working gcc versions I saw:

> - vmov.f64 d0, #6.:e+0
> + vmov.f64 d0, #7.0e+0

Naturally, binutils' assembler fails to recognize "6.:e+0" as a floating-point constant. Where is the ":" coming from?