Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - madscientist159

Pages: 1 [2] 3 4
Blackbird / Re: Regular users issues
« on: April 23, 2020, 12:35:14 pm »

I'm a newbee with PowerPC. I had asked Raptor's support if the Blackbird comes with OS (Debian) preinstalled with the graphical interface. They answered yes.

When I read this thread I got confused. If it comes with Debian preinstalled why would I (I'm a less technical user) bother to install another OS? Although I've done it on x86 directly on the hardware and also as VMs I'd prefer to start with a "working machine" out-of-the-box.

So, when I get the Blackbird, will I be able to use it (as a regular user - email/browser) out of the box? or Will I have to learn how to install the OS on this system?

Thank you all for your patience and attention,

Many people would choose to install their own OS because they either have a favorite OS they want to use instead of the preinstalled one, or they don't trust the preinstalled version for whatever reason (e.g. tampering in transit, etc.).  Since one of the main reasons for people to choose an OpenPOWER system is the fact that they have full control over the hardware, it isn't too surprising that the vast majority of our users exercise that control by loading their own OS and in some cases even compiling and reloading the firmware.  It's not something you have to do, just something that a lot of people choose to do.

The preinstalled OS is perfectly usable for normal tasks.  It is a Debian install with TDE, you could choose a different desktop such as KDE, XFCE, or Gnome if you wanted (apt-get works out of the box).

Talos II / Re: Resetting Talos II to "Factory Settings"
« on: April 22, 2020, 08:35:22 pm »
Apologies for not seeing this sooner.  Our (US-based) consumer support is impacted by the COVID19 situation at the moment, we are currently focusing on business sales/support given the obvious slowdown in consumer interest with the ongoing pandemic, but once that is finally under control we should be able to resume proper consumer support with a much shorter delay.  The biggest problem is no one really knows the timing yet; it could be months or even more 2021 timeframe depending on exactly what happens with the fall "flu" season this year, and that makes most decisions in this area difficult at best.

In regards to the technical problem you have, please try the PNOR here:

The backtrace looks a lot like the crash seen due to an unfortunate last-minute Linux kernel bug affecting the LSI SAS controllers.  The new PNOR applies the upstream fix for it to the kernel underneath Petitboot.

Firmware / Re: New firmware V2.00 BMC procedure
« on: March 17, 2020, 05:19:39 pm »
First, I need to remind you that if the BMC update is done incorrectly (i.e. if the instructions are not followed exactly, including decompressing the image-bmc file BEFORE transferring it to the BMC, or if your power fails in the middle of the update process), you will need to externally flash the ROM.  Given the realities of COVID-19 worldwide, I wouldn't update the firmware at this point unless you knew you had all the parts on hand to be able to recover a bad Flash (Beaglebone Black / Raspberry Pi, SOIC-16 clip, wires, and a power supply).

That being said:

You need to scp the image-bmc file to /run/initramfs on the BMC, like so:

scp image-bmc root@<blackbird BMC IP address>:/run/initramfs/

Make sure the image-bmc file is ~32MB in size before you do this, and that the host power is off.

That will put the file in the right spot on the BMC.  Once that is done, SSH to the BMC and:
<write down the MAC>


After this delay, SSH back in to the BMC and run the fw_setenv commands as mentioned in the instructions.

If you did it correctly, the BMC will now be online, but the host will not IPL until you update the PNOR.  There is nearly zero bricking potential there however, so it should be simpler for you to follow (in fact, I would recommend going to https://<BMC IP address> and using the new point+click firmware updater -- it's a lot easier!)

First, great job in doing this!  Much appreciated.

  • Patch to change the browser's user agent string to be the same as the official
While I understand why this is done, it will result in under-reporting of POWER hardware, and my main concern is that Google may look at (in the worst case) no one using POWER (due to the string reporting x86_64) and continue to reject patches.  I don't know if this is a real concern or not, but thought I'd throw it out there for comments.

Worst case the architecture will become just like the rest of the UA string -- spoofed into whatever is most commonly expected for compatibility reasons.  We're not there yet though in terms of market research.

User Zone / Re: Fedora Linux Thread
« on: February 07, 2020, 11:29:45 pm »
Your mainboard fans also not shown. Got it. Thanks!

Code: [Select]
ipmitool sensor will show you the fan speeds etc. alongside CPU / DIMM / planar temps and power usage.

I guess, you tried ssh root@blackbird ?
Ethernet is connected next to the USB ports?
Did you also try to switch off the PSU for two minutes? And then power on again.

I have connected the correct Net3 adapter (above the USB port) and can see the IP address in my router (MAC address is correct).

I did already switched off the PSU for longer (at least 15 minutes) - last resort is no to completely unplug it.

I have attached a picture of the petitboot screen (keyboard does not work - not even in different USB ports - but works on another computer).

The image shown is a classic symptom of the VGA disable jumper still installed.  Please triple check the correct jumper was removed, and power cycle (pull power from the wall and wait for all lights to extinguish) if the problem persists.

My power supply unit is quite oversized (650 W) and a famous brand.
With a SATA HDD alone it seems to work. I will try out the optical drive in another X86 Linux computer with a similar kernel (but without having a NVMe SSD available) to see what happens.
Changing the PSU would be my "last resort".

Yes, agreed, but was listing it for completeness.

How save is this when the system is powered on and running (risk to damage the main board...)?
And how do I enforce a new PCI bus scan (does reapplying the power to the optical SATA drive cause a new scan?)?

Perfectly safe.  SATA power and data cables are hotpluggable by design (you'll note the long ground pins on each connector, this is specifically for hotplug support).  You don't need to manually rescan anything; the kernel will see the hotplug event automatically and either add the device or fail trying (i.e. you'll probably see something in dmesg regardless of whether this works or not).

Will be my next try, currently I am running with a SATA HDD only and have observed no problems so far.

BTW: If you possible have hints or a link on how to debug a libata/marvel during booting of Linux I would try to do this (I know gdb quite well) but I am sure your time is rare so it is OK to ignore my wish ;-)

To be honest, that kind of hardware incompatibility would be very strange indeed.  Any chance you can try a different card in the same PCIe slot to see if the same problem is triggered?

Interesting thread and issue!

I'd suspect one of the following:
  • Linux driver problem with Marvell controller (would probably be a regression since these used to work quite reliably)
  • Hardware problem -- e.g. PSU sagging slightly under extra load from NVMe drive, causing controller or drive to malfunction

Have you tried (carefully) removing power to the SATA drive when it's in timeout status, and reapplying it, to see if the link comes back up?  Or moving the cable to a different port to see if it's the entire chip that's locked up or just the one port?

Yes, I have read this but I would like to understand the background to make decent decisions on future hardware purchases ("compatibility mode" sounds like "performance impact")

No, it's much the same as "32-bit compatibility mode" in the x86 software context.  The GPUs are broken, not quite spec compliant, so IBM had to introduce additional kernel handling to work around that.  Therefore, "compatibility with old broken GPU hardware", or "compatibility mode"  ;)

If they were not broken, the extra "compatibility" code would not be needed.  You can of course run them in 32-bit mode, but when you exhaust the 32-bit space you'll get GPU memory allocation errors and that very well might crash X or your applications (or the machine, since GPU drivers don't generally handle errors well).

This is no longer an issue with kernel 5.4 and higher.

User Zone / Re: Virtual machine to run x86 software on ppc64le a host
« on: February 01, 2020, 05:00:04 pm »
You're looking for qemu-system-x86_64.  Note that using it may or may not be legal, depending on jurisdiction and emulated CPU model, due to Intel/AMD x86 ISA patents / copyrights.

On the other hand, using QEMU to emulate OpenPOWER, RISC-V, SPARC, etc. should be perfectly clear (might want to verify SPARC ISA status, IANAL etc.).

Blackbird / Re: Want more options for Blackbird™ Secure Desktop
« on: January 31, 2020, 05:07:37 pm »
Also relevant: 2U fan shroud assembly

Nice hack (in the complementary sense)! ;D

Applications and Porting / Re: Software and Games for GPU new generation
« on: January 30, 2020, 06:44:37 pm »
I'll second the Flightgear recommendation.  Crank up all the settings, connect several screens or a giant 4k screen, and watch your brand new top of the line system suffer. ;D

I ended up using an NVMe just to get the loading times down, the best GPU I could get, and oodles of RAM.  Somehow Flightgear stresses the machine even more than UT4 (!), and it's a far more balanced stress test (testing all parts of the I/O subsystem plus CPU power plus GPU power.

I had to turn down Flightgear settings on my old Opterons vs. stock, for what it's worth.

This issue looks very familiar...what kernel version are you on?  Do you have an AMD GPU installed?

Reason I ask is that I tracked down a bug on an older kernel (could have been early 5.x series or mid to late 4.x series, can't recall offhand) that manifested with cores dropping out like this.  Basically, the driver was doing an invalid coherent access, the firmware didn't like that one bit and assumed the CPU was faulty, thus offlining more and more of the cores until it finally didn't have enough to even IPL.

I do know RHEL 7 was great at provoking it.

I'm doing research for a future Talospace article on the ultravisor, but while it should do something conceptually similar I don't think it's an exact replacement for SGX.

Flexver seems to have a little different scope and involves tamper protection as well AIUI, but @madscientist159 could say more about that.

Yes, FlexVer is the technology required to basically harden the systems against direct physical attack.  Since we consider permanent vendor control via e.g. vendor signing keys absolutely unacceptable, some other scheme is required to prevent physical access from silently becoming root / hypervisor root.  That's where FlexVer sits.

We have a few papers online, e.g. and .  There's also some information at , and I'd be happy to answer any direct questions you have.

Since Ultravisor is owner controlled, we'd generally say FlexVer is needed to make sure the Ultravisor image you think you loaded was actually loaded if a hostile physical environment is in play.

@AbstractConcept My standard answer to anyone promoting SGX as a "secure" solution is to ask, do you have an SLA with Intel that will pay out all damages incurred if SGX is implemented wrong, has a firmware bug that allows malicious access, if Intel abuses their keys to gain access to your data (including under court order / with warrant), etc.?  If not, you're just blindly trusting a third party to act in your interests at all times for no real reason.  Not a place I'd like to be, and definitely nothing I'd call "secure".  ;)

Pages: 1 [2] 3 4