Hello,

On 06.07.2018 05:51, John J. Karcher wrote:

...

It also booted on my AMD Ryzen 5 system but it did not detect SATA drives.

FWIW, I was pleasantly surprised to find that my AMD FX-based system mostly worked - the SATA hard drive wasn't detected, but the on-board (Realtek) NIC worked, as did an external USB hard drive.

I haven't tried virtualization yet (because I can't wipe the external drive), but I will try it when I can.

as written on the Sculpt TC release website, a _recent_ Intel-based PC is the main target. So, AMD machines may work to some degree, but it is not expected to work well.

Regarding SATA/AHCI and AMD, in Sculpt TC the driver manager only considers Intel AHCI chips [0], so your SATA disks can't work since no driver is started at all.

It would be great, if AMD users out there test/debug our AHCI driver with some simpler scenario and open up feature issues on github, so that it be added for the next releases.

Cheers,

Alex B.

[0] https://github.com/genodelabs/genode/blob/master/repos/gems/src/app/driver_m...

I'm not sure if the GMA 4500 video chip is supported by Genode, if you have an old VESA video card lying around, you might have some more luck on the Dell. It is an integrated Intel 82Q963/Q965. I have tried with a radeon 7200 (R100 PCI card)... my monitor complains on resolution (Linux too), and reboot like before. I have tried with a GT 400 card, it seems to reboot faster (like puting the computer like in sleep before rebooting). So it's probably linked to the computer itself rather than to the graphic card.

On 07/06/2018 02:30 AM, Nobody III wrote:

What AMD FX hardware did you get to work? Mine seems to have ACPI/interrupt issues. Because of this, only output hardware works. I can use fb_drv, but not usb_drv, ahci_drv, or nic_drv.

It's an Asus Sabertooth 990FX motherboard with AMD FX 8120 CPU and 16GB of RAM.  The video card is a Gigabyte HD7750 (Radeon-based), but that's probably irrelevant, as I assume it's running in VESA mode.

Like I said, I haven't tried virtualization yet, but it booted from the USB stick, saw the external USB drive, connected using wired networking, and installed packages from the internet.  It didn't like my ThinkPad keyboard with built-in TrackPoint, but neither do the BIOS setup screens.

What part of Sculpt depends on IOMMU hardware? I'm asking because I'm trying to debug interrupt-related issues with the IOMMU disabled to simplify things.

On Fri, Jul 6, 2018 at 3:58 AM, Emery Hemingway ehmry@posteo.net wrote:

Ok, to clarify, anything with a parallel port is a no-go for Sculpt. Sculpt require IOMMU hardware, I can't say when the IOMMUs appeared, but its safe to assume you will not find an IOMMU and a parallel port on the the same machine.

I still have a favorable opinion of the Dell Optiplex line of desktops, and I would consider running Genode on one myself, but this would be an "OS" different from Sculpt. A kernel other than NOVA would need to be selected, there would be no need for UEFI support, and the ACPI setup might need to be tweaked. It could be a fun project for the weekends, but Plan9Front would run at least as well on the same hardware.

Regards, Emery

On Friday, July 6, 2018 11:25:23 AM CEST, Emery Hemingway wrote:

...

Hello list,

As a rule of thumb, anything with a parallel port is unsupported hardware.

Cheers, Emery

---

Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users

On 07/06/2018 03:44 PM, Paul Dufresne wrote:

I have built the run/demo on Nova, burn the demo.iso on a CD, and tried it on my Dell Optiplex 745. Does reboot in loop too.

I am considering making a program that just loop to stop the reboot loop. :)

Hi Paul,

I've ran the boot loop on my Optiplex 380 and got this output. Hope it helps you diagnose your problem.

# cu -s 115200 -l /dev/ttyS0 Connected. Bender: Hello World. framebuffer at [b8000+b8fa0) 80x25@16 warning - unknown framebuffer type framebuffer at [b8000+b8fa0) 80x25@16 warning - unknown framebuffer type

NOVA Microhypervisor v7-9b24eb4 (x86_64): Jun 12 2018 22:09:48 [gcc 6.3.0] [MBI2]

cu: Got hangup signal

Disconnected.

Cheers, Guido.

Alex wrote:

I would suggest to instrument NOVA and see up to which point it gets.

Well, because I had no VGA output at all, I thought that bender was not working. I removed it from GRUB config, and start with the kernel. This does not help.

I also try the different parameters to Nova, but without change. (The most obvious one was removing IOMMU).

The bring-up of the other CPUs/Hyperthread seem to be missing in your log output. ([ 0] CORE:0:0:0 6:f:b:0 ....).

You are misled, this is not mine outout. I don't have serial output (I 'stupidly' throw away my serial null cable).

I followed your suggestion to update BIOS. BIOS gone from 2006 version to late 2011 one. Now dmidecode does way much more nice information! (was having just about 5 short hexadecimal tables before). But that did not help.

I am not too sure how to keep a version of the Nova kernel to work on. I searched for the source, but it does not seems to be kept in after the prepare... which leave the the compiled .o and compiled hypervisor in the bin? directory of the build directory.

That said, I got a look at the code on https://github.com/udosteinberg/NOVA/tree/master/src And it looks way too familiar. In fact, I think I had isolated similar if not exact same symptom when I work on that few years? ago.

When I look in init.cpp code: extern "C" INIT REGPARM (1) void init (mword mbi) { // Setup 0-page and 1-page memset (reinterpret_cast<void *>(&PAGE_0), 0, PAGE_SIZE); memset (reinterpret_cast<void *>(&PAGE_1), ~0u, PAGE_SIZE);

for (void (**func)() = &CTORS_G; func != &CTORS_E; (*func++)()) ;

Hip::build (mbi);

for (void (**func)() = &CTORS_C; func != &CTORS_G; (*func++)()) ;

// Now we're ready to talk to the world Console::print ("\fNOVA Microhypervisor v%d-%07lx (%s): %s %s [%s]\n", CFG_VER, reinterpret_cast<mword>(&GIT_VER), ARCH, __DATE__, __TIME__, COMPILER_STRING);

I can like remember that I was blocking in these constructors code calling functions loops (more the second one from memory). I believe I was back then using the same technique I was to use here: adding while (1) line to see when it hangs and when it reboots.

I can see they are coming from hypervisor.ld file: .init_array : AT (ADDR (.init_array) - OFFSET) { PROVIDE (CTORS_L = .); KEEP (SORT_BY_INIT_PRIORITY(*)(.init_array.65534 .ctors.00001)) PROVIDE (CTORS_C = .); KEEP (SORT_BY_INIT_PRIORITY(*)(.init_array.65533 .ctors.00002)) PROVIDE (CTORS_G = .); KEEP (SORT_BY_INIT_PRIORITY(*)(.init_array.* .ctors.*)) KEEP (*(.init_array .ctors)) PROVIDE (CTORS_E = .); } : kern but that's looking like black magic to me. I suspect this is a way to do what a C++ runtime would do to call static class constructors... but this is mostly a guess from the .ctors name.

Anyway, back then I believe the code was not taken from git hub at prepare time, then erased after prepare. And now, I am unsure if I must write patches in the patch directory or what. I really wish I would have the Nova source kept, and that make would recompile Nova on demand but I have pretty much no clue how to achieve that.

I have realized that if I set the CPU to coreDuo in QEMU rather than core2Duo, my run/bomb program would not give any output at all.

My real CPU is a dual core. But the BIOS does not enable virtualization per default. I believe I have a CPU with vmx flag, that does not have IOMMU (dmidecode does not show a DMAR (DMA relocalistion) table).

Here is my /proc/cpuinfo: processor    : 0 vendor_id    : GenuineIntel cpu family    : 6 model        : 15 model name    : Intel(R) Core(TM)2 CPU          6300  @ 1.86GHz stepping    : 6 microcode    : 0xd0 cpu MHz        : 1821.338 cache size    : 2048 KB physical id    : 0 siblings    : 2 core id        : 0 cpu cores    : 2 apicid        : 0 initial apicid    : 0 fpu        : yes fpu_exception    : yes cpuid level    : 10 wp        : yes flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm pti tpr_shadow dtherm bugs        : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass bogomips    : 3721.03 clflush size    : 64 cache_alignment    : 64 address sizes    : 36 bits physical, 48 bits virtual power management:

I had the idea to test run/bomb in QEMU with my host CPU, but after installing a KVM linux kernel, it was not booting (if BIOS have virtualization enabled, would hang on loading boot image kind of message).

I do remember that a few years ago, the author of Nova, had it modified so that it booted on my Pentium 4. But I guess something went wrong with the years. He sure did not really happy back then to know that people where still using CPU that does not support IOMMU.

I tried with Pentium3 emulation and QEMU after 3 to 5 mins, said that the program had try to write outside memory, and that it probably means I was running an image not compatible with my machine.

Now, I suppose that the fact QEMU cannot handle some older CPUs on Nova well... that there is some way to debug it in an easier way than on real hardware? I am still trying to figure how ... however.

For the record, I have used NOVA on KVM without any issues. However, as of Genode 18.02, Genode/seL4 doesn't boot on KVM.

On Wed, Jul 11, 2018 at 2:21 PM, Alexander Boettcher < alexander.boettcher@genode-labs.com> wrote:

On 11.07.2018 18:24, Paul Dufresne wrote:

...

I have realized that if I set the CPU to coreDuo in QEMU rather than core2Duo, my run/bomb program would not give any output at all.

We know, thats why the default CPU for NOVA on Qemu is Core2Duo (and nothing older) in our run tool.

...

My real CPU is a dual core. But the BIOS does not enable virtualization model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz

Theoretically, this is sufficient for the NOVA kernel.

...

I had the idea to test run/bomb in QEMU with my host CPU, but after installing a KVM linux kernel,

You are at your own. KVM caused in the past trouble and we did abandon the idea to use it with the NOVA kernel.

Paul,

if you really really really want to get this running on this very very very old CPU, we need to have serial output. We can't work with guesses or any attempts to run it virtualized. On the other hand, why you want it ?

For Genode Sculpt TC we don't envision to run on such old hardware. Even if you get it booted, it will make no fun to use with Sculpt (to few memory, to slow CPU, not supported network card, no IOMMU support, virtualization support is unclear etc etc...)

What about our suggested hardware [0,1] for Sculpt TC ? Refurbished versions of the machines are not that expensive - or at least some more _recent_ Intel machine - if you are really interested. If you just want to give it a spin without the desire to run it on a daily basis, running Sculpt TC in a VM should be sufficient.

[0] https://genode.org/documentation/articles/sculpt- tc#Hardware_requirements_and_preparations [1] http://usr.sysret.de/jws/genode/hcl.html

Cheers,

-- Alexander Boettcher Genode Labs

http://www.genode-labs.com - http://www.genode.org

Genode Labs GmbH - Amtsgericht Dresden - HRB 28424 - Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

---

Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users

On 12.07.2018 17:41, Paul Dufresne wrote:

I spent many hours trying to figure out what is going wrong when running Nova on my Optiplex 745 machine.

I have figure out that the computer would reboot unless I commented out: In si.cpp constructor, the TRACE line have to be commented out.

This should not happen nor necessary to comment it out, as long as you did not enable TRACE_SYSCALL (which is by default off).

Id pd.cpp constructor, the Mtrr::init(); have to be commented out.

Also, to see what is going on on the screen, in: genode/tool/run/boot_dir/nova, I have removed novga from: #proc kernel_output { } { return "novga serial" } This allow to see some info on the screen.

My 2 CPUS are shown on the screen. But that's the last thing that is shown. It looks like the schedule call at the end of bootstrap.cpp does not seems to kick in. I am unsure where is the code that is supposed to be run from there... or/and why it is not run.

Check, whether the timer interrupt (local APIC) is working on your CPUs. If they are not, the scheduling will not work properly.

You may try to add "spinner" to the kernel commandline. This gives you some diagnostic information about all kind of events and interrupts coming in (see chapter "Console" at the end in contrib/nova-<hash>/src/kernel/nova/doc/specification.pdf)

Another commandline option is "keyb", which gives you (if the keyb interrupt is working properly) on each "c" key press additional information on the vga screen and/or serial.

Good luck,

Hi Paul,

On 13.07.2018 17:07, Paul Dufresne wrote:

simple in include/mtrr.hpp, also stop the computer from rebooting. I have added in mtrr.hpp: in private:         static Quota        paulcache[200];     public:         ALWAYS_INLINE         explicit inline Mtrr (uint64 b, uint64 m) : List<Mtrr> (list), base (b), mask (m) {}

ALWAYS_INLINE         static inline void *operator new (size_t, Quota &quota) {           static Quota *paulptr;           //return cache.alloc(quota);           *paulptr=quota;           return(paulptr++);

whatever you try to do here, it is wrong.

You take a reference as input (Quota &quota), store it in a static and later on just increment the static. Whatever lies behind Quota &quota stored in the static will wrongly read and/or overridden/corrupted !? (If you tried to use paulcache, it is not used.)

On 12.07.2018 17:41, Paul Dufresne wrote:

Id pd.cpp constructor, the Mtrr::init(); have to be commented out.

According to the Intel Architectures Software Developer’s Manual, not all CPUs may implement MTRR. (Chapter MTRR Feature Identification).

Looking at the Mtrr:init() code, there seem to be a feature check missing. If you adhere to the Intel manual documentation, you should be able to implement and test this check.

I think I finally come to a real Genode problem (rather than a platform one):

On X86_64, I ran:

make KERNEL=foc run/framebuffer

and running on my Dell Optiplex 745, with integrated i965 I got:

Error: acpi table out of range - 0xfff69ab8 not in [ 0000000000000000 ,

000000003fffffff )

See how it finished with ) rather than the expected ]

More seriously, who put a limit on where my acpi table can be?

Guess, I will be expected to fill bugs soon rather than clutter the mailing list.

I am confused because the VGA framebuffer says that it's default configuration is 1024x768.

But when ran in QEMU I see: (for run/framebuffer)

[init -> fb_drv] Found PCI VGA at 00:01.0 [init -> fb_drv] fb mapped to 0x6000 [init -> fb_drv] Found: VESA BIOS version 3.0 [init -> fb_drv] OEM: SeaBIOS VBE(C) 2011 [init -> fb_drv] Found: physical frame buffer at 0xfd000000 size: 16777216 [init -> fb_drv] fb mapped to 0xb000000 [init -> fb_drv] using video mode: 2560x1600@16 [init -> test-framebuffer] framebuffer is 2560x1600@RGB565

I know this is vesa driver speaking... but from where 2560x1600 is coming from?

Hello Paul,

On 07.07.2018 12:50, Paul Dufresne wrote:

I am confused because the VGA framebuffer says that it's default configuration is 1024x768.

...

I know this is vesa driver speaking... but from where 2560x1600 is coming from?

nowadays the VESA driver tries to set up the highest possible resolution by default. But you can explicitly configure it to use a particular resolution:

<config width="1024" height="768"/>

BTW, I noticed that you post on the mailing list at a very rapid rate. I kindly request you to be a bit more considerate towards the many subscribers of the list. Instead of creating a batch of ad-hoc postings - some of them without any formatting whatsoever - I would greatly appreciate you collecting your thoughts and questions in one succinct posting. Otherwise, I fear that the discussion culture of the mailing list may degrade to a chat room. For casual talk, you may also consider the IRC channel #genode at freenode.

Cheers Norman