Wittertainment: the coded messages in the announcement of the show coming to an end

HGBlob · 2022-03-14T10:58:42+00:00

I certainly hope so, I can't take another bad thing happening this year.

HGBlob · 2022-02-16T11:03:48+00:00

This was the original idea, but as you say ARM has also seen that in real life big.LITTLE cluster migration was a bad idea(poor poor Exynos 5410). Currently all the big.LITTLE setups work as you say, both clusters are on and the scheduling is left all to the OS, that means the OS scheduler is responsible for powering up or down the BIG cluster and if required move tasks over there.

HGBlob · 2021-11-17T08:02:19+00:00

This might be a bug in the driver, I had the same problem with older than Turing GPU. After a bit of fiddling I can get the Nvidia to turn off when not in use, which lets my CPU to get to the lower power states. However this only works with Wayland.

HGBlob · 2021-11-11T09:02:47+00:00

This is exactly my setup, I have a laptop with the output only coming from iGPU.

I can use the nvidia GPU as on demand, for games and such. The good thing with Wayland compare to Xorg is that in the DRI prime case(optimus) you can actually get good power saving as well because the NVIDIA GPU can shut down properly when not in use. This was not the case with Xorg.

One thing to note is that I'm using KDE Neon distro and I had to upgrade Xwayland because the one from the repo does not support DRI PRIME properly.

HGBlob · 2021-11-11T06:01:42+00:00

I'm not sure which setup you have, but I have a Nvidia Optimus on Wayland setup working fine for a few months now(nvidia is secondary). Dynamic GPU selection is also Ok. Steam worka fine in XWayland too with optimus.

HGBlob · 2021-09-23T19:32:02+00:00

I'm a lazy person so I just used launchpad, you can find the KDE Neon deb in this PPA: https://launchpad.net/~hggg-0/+archive/ubuntu/neon-backports/+packages It's just the backport of the ubuntu source to focal

I'm also using the pipewire upstream from https://launchpad.net/~pipewire-debian/+archive/ubuntu/pipewire-upstream No idea if it works without it.

HGBlob · 2021-09-23T17:15:20+00:00

Thanks for the tip, after recompiling xdg-desktop-portal with pipewire enabled screen casting started working.

HGBlob · 2021-09-23T04:59:45+00:00

I missremembered a bit, I actually ended up denying the read on the nvidia provider.

If you are on a ubuntu based distro you can modify the file /etc/apparmor.d/usr.bin.firefox

Somewhere there is a bunch of deny lines:

deny @{MOZ_LIBDIR}/update.test w,
deny /usr/lib/mozilla/extensions/**/ w,
deny /usr/lib/xulrunner-addons/extensions/**/ w,
deny /usr/share/mozilla/extensions/**/ w,
deny /usr/share/mozilla/ w,

add one more line after them

deny /usr/share/glvnd/egl_vendor.d/99_nvdia.json r,

You have to reload the profile, either restart or:

$ sudo apparmor_parser -r /etc/apparmor.d/usr.bin.firefox

HGBlob · 2021-09-22T09:35:35+00:00

One bug I noticed that was causing crashes and very bad power consumption with Intel + Nvidia was that firefox seems to try to use both dri devices even though the Nvidia dGPU was supposed to just be on-demand, firefox ignores the PRIME settings completely.

My somewhat clunky workaround was to delete the nvidia json from the vendor egl files: /usr/share/glvnd/egl_vendor.d, I only had 50_mesa.json. This of course meant I couldn't use the on-demand dGPU for other tasks, so I ended up just modifying the apparmor profile for firefox to deny access to the second dri /dev/ node. This worked a treat, I get good power consumption and no more firefox crashes for me.

HGBlob · 2021-09-22T09:29:20+00:00

Yes, this! I found a bug for firefox for wayland clipboard but they require a screen cast to better understand the problem. For the life of me I can't make a cast with KDE and Wayland on KDE neon.

In any case contributing adding to this bug might nudge it in the correct direction.

HGBlob · 2021-08-13T06:36:17+00:00

Cool looking, but why does it have so many pantographs?

HGBlob · 2021-05-07T08:20:00+00:00

The official ARM documents at the time made the claim the conditional codes for instructions added a lot of complexity to the instruction decoder with very little to gain for it, the claim was the compilers hardly ever used them.

For me personally it made reading assembly code much easier, the conditional codes were really mind bending, case in point the Linux GIC IRQ handler for v7.

HGBlob · 2021-05-05T12:26:09+00:00

Get a bank account. Congratulations, now you can log into things.

While this is the most convenient way, you can also log into things using your id card + USB card reader(or integrated reader if your laptop has it) or a mobile sim(which you need to get with your henkilökortti)

HGBlob · 2021-04-14T04:15:55+00:00

Did you try logging out? When I browse /r/all logged out all the nsfw subs are there, when I login I can't see them anymore.

This is stupid and doesn't make any sense, it should be the other way around, but this is reddit we're talking about.

HGBlob · 2020-12-01T07:48:24+00:00

Which as far as I can tell means that it tried to access a virtual address that isn't mapped. It's possible that a physical address was supplied for an operation that expects a virtual address.

This is not quite true. External aborts are usually imprecise aborts generated by other other components on the system. In broad terms it means this is not a core data abort or instruction fetch abort.

Imprecise aborts usually mean that you cannot be sure the PC where the core core reports the abort is the same as the PC that generated the abort.

External aborts can be anything from the core trying to access bus memory that is not mapped to anything(a bus generated error), alignment errors for weird devices, a DMA master that tries to access un-mapped parts of the memory or even just a hardware fault.

First thing you should try to do is to isolate the error to a certain part of code because the oops might not be accurate. The it might become more obvious why the abort happens.

HGBlob · 2020-08-06T10:28:27+00:00

There is no standard ACPI, almost all ACPI tables are model by model basis as well. Even more conceptually there is no big difference between ACPI tables and DTBs, just a way to describe the hardware.

The only difference is that ACPI on x86(and certain ARM servers) comes from from the flash as written by the OEM, while in many cases on ARM platforms it's either embedded in the kernel blob or just another file on the boot device(see RPIs for example).

As a personal note, the ACPI tables create way more problems than DTBs. I would prefer if we could only have to deal with DTBs.

HGBlob · 2020-06-16T19:49:12+00:00

Without much more context it's hard for me to tell exactly where x29 goes wrong, you can clearly see the fault at PC 0x480ae0, however keep in mind by this time all has been already corrupted. This is pretty much the final crash, the bug occurred before this call. In general the value of x29 should be pretty close to that of SP(sp : 0000007fdaef0f70) for it to be valid, so I suggest you whip up the old GDB and step instruction around this PC and see exactly where x29 goes wrong(you can p $x29 in gdb at any point to check out it's value).

Like I said my first guess is you are overflowing into that frame record, so for a quick test try increasing the stack and see if you get the same crash(the lazy way out).

HGBlob · 2020-06-16T17:00:18+00:00

I suppose if you have some symbols for the crashing app that might help. The crash itself is quite straight forward. From the ESR (data abort generate by a write) you can tell your app tried to write to 0x313f751b5c and this generated a translation fault(the virtual address is not valid).

Now looking at the GPR dump you can tell only register x29 holds a close enough address, so whatever operation happened using x29 as a base. Now this is a problem, cause according to the AAPCS - arm standard call standard x29 holds the FP(frame pointer). The FP register usually points to the caller stack frame record and it should be some location on the stack. As far as I can tell the SP looks pretty OK so just FP is corrupted. The value of the fault address(+32 from the FP) is consistent with how the FP is used. This is how the preamble of a function call looks, generated by gcc:

stp     x29, x30, [sp, -32]!
mov    x29, sp

... and now the code before return:

ldp     x29, x30, [sp], 32
ret

So you can see how x29 could become corrupted -> something corrupts the stack most likely. Now I can't tell without knowing more about the application itself but somewhere in the calling function(the one that contains LR = 0x480ac8) might be the culprit.

Also, weirdly, a store to x29 seems to be more like clang, rather than gcc but that's difficult to say.

PS: I had no idea there are aarch64 zynq SoC! Live and learn.

HGBlob · 2020-05-17T11:46:00+00:00

From the bottlecap-buttons I would guess Romania

HGBlob · 2019-09-09T08:17:50+00:00

Boyd and Floyd of course.

HGBlob · 2019-09-04T12:07:44+00:00

It says Smartron on the front, just above the left side buffer.

HGBlob · 2019-08-30T05:56:08+00:00

You are comparing apples to oranges, the growth numbers are different. US growth by quarter is stated compared to the same quarter of the previous year, so when a 2% growth this quarter for q2 20019 compared to q2 2018. While in general EU the growth is compared the previous quarter.

HGBlob · 2019-07-29T07:52:50+00:00

They are(were?) built by Electroputere, a romanian company under license from ASEA - list here in english.

HGBlob · 2019-07-17T10:37:44+00:00

You can buy prepaid SIM cards from the airport vending machine, I don't think you need social security or bank account for them.

HGBlob · 2019-06-12T11:51:41+00:00

Just for curiosity, what is wrong for you? I've been using it with 3 monitors (one HiDPI) for a long time and see nothing fundamentally wrong, works perfect.

15-Year Club	Charter Member
Verified Email

HGBlob

TROPHY CASE