Messages

1

Talos II / Re: Advice for installing OS via BMC?

« on: February 08, 2021, 10:26:01 am »

@SiteAdmin is Raptor, or at least someone on their technical staff.

That's correct -- it's a shared account for moderating and some limited interaction.  We were responding here since it made sense to potentially pull in some community resources depending on what you were looking to do.

Did you set the date to a correct value? Otherwise Ethernet will not work.

That's the first I've ever heard of that...

Likewise.

Regarding DHCP, when the test machine was provided to you there were two static IP addresses given.  The first was for the BMC (already configured), and the second was to configure the connected inferface (the one shared with the BMC).  Once you configure the interface to that IP address, you will have full connectivity.  There is no DHCP on the network segment the evaluation machines are connected to.  You would need to use a public DNS resolver such as 1.1.1.1, 8.8.8.8, or 9.9.9.9.

2

Applications and Porting / Re: QtWebEngine status (depends on Chrome / Chromium patches)

« on: January 27, 2021, 10:51:09 am »

Hey Daniel, do you mean there is a hang on this patch and therefore all Chromium development on Power has stalled? Damn you have to try to fix it then, you can't even download it anymore and it's a shame because it's the best together with Firefox and it's a big lack for us in my opinion ...

It's still being updated:

https://github.com/leo-lb/ungoogled-chromium/commit/362ec8584e373b798f9e3e45f4791b2dae2d0ee3

As usual, Google is not interested in merging patches, but that doesn't mean the community can't keep working around them downstream.  As far as what it will take to convince Qt...well, that's another organization that has a long history of ignoring user requests.  If there's a way to patch Qt downstream based on the existing Chromium port, that's probably the best bet.

As far as Google "killing" Chromium, all I see is they're moving the Google backend access into the proprietary builds.  From my perspective, that's actually a plus -- no hidden sync with Google servers when using the open versions, and less to need to "unGoogle" over time.  Frankly, if one is OK sharing all that data with Google in the first place, why not go buy a Chromebook or use Windows on x86.... 

3

Applications and Porting / Re: Chromium and Ungoogled Chromium DNF Repository

« on: January 27, 2021, 10:46:49 am »

I did some digging around today, it looks like the repositories are still being updated, and 88 might be buildable as of around a week ago:

https://github.com/leo-lb/ungoogled-chromium/commit/362ec8584e373b798f9e3e45f4791b2dae2d0ee3

I'll have to give it a try at some point...

4

Applications and Porting / Re: Chromium and Ungoogled Chromium DNF Repository

« on: January 27, 2021, 01:32:59 am »

I'm also a bit curious about what's happening with the Chromium port...Firefox is still very painful to use (no JIT) and it doesn't look like anyone has updated the Ungoogled/POWER port for a while now?

Typing this from a Blackbird on Ungoogled Chromium...

5

General OpenPOWER Discussion / Re: Talos II arrived

« on: September 03, 2020, 04:51:01 pm »

I like the LSI HBAs -- good open source Linux driver support, ubiquitous, stable, and they work just fine with the IOMMU active (the latter is important since every SAS HBA on the market uses a sizeable firmware binary on the card side of things).

Needless to say I also strongly recommend LUKS for data security and integrity purposes.

6

General Discussion / Re: Fractal Design cases

« on: September 03, 2020, 04:47:50 pm »

A couple of notes...

The old style 3-pin fans would run at full speed all the time.  I'd personally replace them with modern 4-pin fans unless they're nice and quiet at full power (or the case is controlling their speed somehow with a sensor).

The Talos II fan headers can supply quite a bit of +12V power, just watch out for the connector(s) you attach to the header(s).  Just because the mainboard can supply a lot of amps safely doesn't mean the attached third party fan connector can actually handle that current without damage (melting, fire, fusing, etc.).

7

Blackbird / Re: How many fans per FAN header?

« on: May 22, 2020, 12:52:00 pm »

So if you look at the schematics, you can see the fan power pins are wired straight to the main +12V supply rail.  This in turn is normally provided through either a power plane or a fat trace, meaning the power limit will be the fan header itself -- in fact, given the fan power header is comprised of standard stake pins, the power limit is more precisely in the fan connector itself.  Many of the cheapest Chinese fan connectors appear to use non-soldered (crimped) connections to what seems to be horse hair instead of copper wire, meaning I would be very concerned about pulling even an amp though them.

If you can get a high quality connector, the fan headers themselves are likely good for ~5A.  Problem is, if your connector melts down / catches fire, it will damage the header and the PCB, and that would not be covered under warranty, so please be sure of the quality of the mating connector before trying to pull 5A... 

8

Operating Systems and Porting / Re: Virtualization Extensions are unavailable

« on: May 19, 2020, 04:26:14 pm »

Hi,

Thanks. I've succeeded to create a VM using virt-manager.

But the path /dev/kvm does not exist in my file system. Does that mean that I'm running software virtualization and not hardware virt?

Regards

Good to hear you got it working.  If you're not noticing the VMs being extremely slow, then you're using hardware virtualization.  It's possible Fedora doesn't ship with the /dev/kvm device node, but I'll admit to being a bit out of my depth with the RPM-based distros.

You could try "sudo virt-host-validate" (provided by libvirt-client) and see if that shows anything on the actual status of the virtualization support?

9

Operating Systems and Porting / Re: Virtualization Extensions are unavailable

« on: May 19, 2020, 01:35:13 pm »

I saw that error from the GNOME Boxes.

Sounds like a bug in GNOME Boxes, which to be honest isn't an application I'd heard of before today.  Can you try a different application like virt-manager?  You might want to file a bug report against GNOME Boxes as well.

If I run the command egrep '^flags.*(vmx|svm)' /proc/cpuinfo I also get no response. Any idea?

Most architectures don't report their hardware support flags in /proc/cpuinfo, that's pretty much an x86-only thing.  POWER has full virtualization support in Linux, it's not something that can be turned off unless you build a kernel without the needed support.  If you look for /dev/kvm, you should see that it exists, that's all you need.

10

Firmware / Re: Blackbird firmware build fails on Blackbird

« on: May 19, 2020, 11:34:39 am »

Discussed this some with the IBM team, the issue will be handled here:

https://github.com/open-power/op-build/issues/3634

11

Operating Systems and Porting / Re: Virtualization Extensions are unavailable

« on: May 19, 2020, 11:29:04 am »

Hi,

I've got my new Blackbird and installed Fedora 32 on it, KVM and GNOME BOXES. When I try to create VMs I get the following error messages: "Virtualization extensions are unavailable on your system. Check your BIOS settings to enable them".

I've tried all options on PetitBoot menu but could not find how to enable virtualization extensions.

Anyone had this issue? Any help is welcome.

Thanks,

Virtualization is always enabled.  Are you seeing that error from a specific piece of software or from the direct QEMU command line?

12

Firmware / Re: Blackbird firmware build fails on Blackbird

« on: May 16, 2020, 12:52:23 am »

I got the full log file but as it exceeds the attachment file size limit I temporarily uploaded it onto my server.
Here it is: http://3.1.2.2/temp/fullbuild.log

Thanks!  Next time you might try compressing it, as it's just plain text I'm sure the compressed version would end up a lot smaller than 42MB... 

Do you see "cc1: error: no include path in which to search for stdc-predef.h" line in the full log on your x86 box?  I have no practical way to test (no easy access to an x86 machine).

13

Firmware / Re: Blackbird firmware build fails on Blackbird

« on: May 14, 2020, 02:00:02 pm »

Can you post the build log from a full clean build?   This one looks like it was restarted, and from the error messages I'm guessing the toolchain didn't compile correctly.

The fastest way to make this work for sure is to install a Debian Stretch chroot, bind mount /proc, /sys, and /dev, then build inside that chroot.  I don't think IBM fully supports the newer software versions in Buster, and from the log I can't (yet) determine why it'd fail on POWER other than it's possible the native compile path is different and somehow broken on Buster.

I'd like to see this fixed, but I'm not 100% sure when I'd have time to get a new environment set up and test build, which is why I'd like to see the full log from scratch build.  Maybe it's something simple (missing package?)   

14

Firmware / Re: Blackbird firmware build fails on Blackbird

« on: May 12, 2020, 05:11:07 pm »

So you're saying it's only failing on a ppc64le host?  Can you post the full output log?

We use Debian Stretch to build the firmware (on POWER) internally, as IBM hasn't really tested newer versions of some of the underlying software (the XML libraries are a particular problem, as is Perl).

15

General Discussion / Re: heat and noise / remote KVM access

« on: May 07, 2020, 08:42:32 pm »

I tend to use fiber converters for this sort of thing -- you usually find them used to drive digital signage, remote projectors, etc.  The display converters tend to be "dumb" high speed media converters, but the USB converters are a bit more intelligent, and the USB 3.0 ones are not cheap.  That said, fiber means lightning protection (EMP proofing) comes along for free -- in the midwestern / southern US (and I think parts of the UK / France / Germany?) this is a fairly big deal.

All that said, I use a Blackbird, and I don't find it very loud or hot.  If you want more than the 4 core though and a lot of disks etc., I can understand the desire to locate the machine away from the desk.  Human operating tolerances are narrower than modern computing equipment tolerances.