QEMU Bug in macOS 14: No "Hello, World" in `post-02` - just a black screen.

Question

QEMU Bug in macOS 14: No "Hello, World" in `post-02` - just a black screen.

nskobelevs opened this issue 8 months ago · comments

Having issue with "Hello, World!" now being displayed in QEMU.
Didn't work with my own code - tried the post-02 branch as a sanity check but it didn't work there either.

OS: MacOS Sonoma 14.0
rustc Version: rustc 1.75.0-nightly (475c71da0 2023-10-11)
QEMU Version: 8.1.1

Video:

Screen.Recording.2023-10-13.at.21.21.53.mp4

Nikita Skobelevs · Answer 1 · Sat Oct 14 2023 04:33:14 GMT+0800 (China Standard Time)

post-03 seems to work though:

Матвей Т · Answer 2 · Sat Oct 14 2023 06:10:12 GMT+0800 (China Standard Time)

There seems to be a trend of MacBooks not being able to run post-02.
Lemme see...

Edit: See #1249 (comment)

Philipp Oppermann · Answer 3 · Wed Oct 25 2023 20:49:44 GMT+0800 (China Standard Time)

Thanks for reporting this issue! Are these M1/M2 Macs or older ones?

post-03 seems to work though:

That's surprising.. Both branches are writing to the VGA text buffer at 0xb8000, so I don't really understand how one of them works but the other doesn't...

Nikita Skobelevs · Answer 4 · Wed Oct 25 2023 20:56:04 GMT+0800 (China Standard Time)

Are these M1/M2 Macs oder older ones?

These are the newer ones that started releasing in 2020 with Apple's new series of ARM chips ("Apple Silicon")

Philipp Oppermann · Answer 5 · Wed Oct 25 2023 21:32:38 GMT+0800 (China Standard Time)

I just tried to reproduce this issue on an M2 MacBook Air, but the post-02 branch worked as expected for me.

Nikita Skobelevs · Answer 6 · Thu Oct 26 2023 00:14:43 GMT+0800 (China Standard Time)

It's unlikely to be an issue specifically with M1 vs M2 given architecture is the same as far as I know.

What was the OS, QEMU & rustc versions on the M2 you used? - perhaps something is different there

Tom Tang · Answer 7 · Tue Oct 31 2023 21:40:48 GMT+0800 (China Standard Time)

Same here - the post-02 branch only outputs a blank screen. I'm with an M1Pro Macbook Pro.

Here are the versions that I'm using:
rustc: rustc 1.75.0-nightly (31bc7e2c4 2023-10-30)
QEMU: 8.1.2
OS: macOS Sonoma Version 14.0 Beta (23A5312d)

rprovodenko · Answer 8 · Mon Nov 20 2023 04:47:49 GMT+0800 (China Standard Time)

The line width is different (160, not 80 as the code in post 3 assumes), and the first line is invisible. If you change the function to

#[no_mangle]
pub extern "C" fn _start() -> ! {
    let vga_buffer = 0xb8000 as *mut u8;

    for (i, &byte) in HELLO.iter().enumerate() {
        unsafe {
            let line_offset: isize = 160 * 2;
            let char_offset_within_line: isize = i as isize * 2;
            let color_offset_within_line: isize = i as isize * 2 + 1;
            let char_offset = char_offset_within_line + line_offset;
            let color_offset = color_offset_within_line + line_offset;


            *vga_buffer.offset(char_offset) = byte;
            *vga_buffer.offset(color_offset) = 0xb;
        }
    }

    loop {}
}

You get the first fully visible line

And:

let line_offset: isize = 160 * 24;

gives

Looking at the code of post 3 I see that it starts writing from column 23. So yeah, that's the problem. Maybe qemu has an ability to specify different settings for VGA, but it seems that it just doesn't display the 0 line with in the current setup

rprovodenko · Answer 9 · Mon Nov 20 2023 05:09:09 GMT+0800 (China Standard Time)

#1252 is the fix

Матвей Т · Answer 10 · Mon Nov 20 2023 08:26:34 GMT+0800 (China Standard Time)

This seems to be related to an issue on how Qemu works on MacOS. Specifically some bug, only visible in certain versions of Qemu...

Qemu Versions affected (going from comments): 8.1.1 and 8.1.2. Both of these are obtainable from Homebrew. MacPorts seems to be outdated and only hold the 8.0.5 version... could anybody test to see if that one is affected ?

Vladimir Kuznetsov · Answer 11 · Mon Nov 20 2023 21:59:54 GMT+0800 (China Standard Time)

I've got the same problem, just figured out that the first line with "Hello world" is visible in full screen mode.

Philipp Oppermann · Answer 12 · Tue Nov 21 2023 23:29:53 GMT+0800 (China Standard Time)

What was the OS, QEMU & rustc versions on the M2 you used? - perhaps something is different there

I'm also using 8.1.2 installed through homebrew. I just tried it again with the latest rustc nightly (2023-11-20), but I still see the expected output on the post-02 branch. I'm on macOS 13.5.2.

I've got the same problem, just figured out that the first line with "Hello world" is visible in full screen mode.

Interesting! Maybe it's just a window sizing bug then. Are you all on MacOS 14?

Матвей Т · Answer 13 · Wed Nov 22 2023 00:27:04 GMT+0800 (China Standard Time)

What was the OS, QEMU & rustc versions on the M2 you used? - perhaps something is different there

I'm also using 8.1.2 installed through homebrew. I just tried it again with the latest rustc nightly (2023-11-20), but I still see the expected output on the post-02 branch. I'm on macOS 13.5.2.

I've got the same problem, just figured out that the first line with "Hello world" is visible in full screen mode.

Interesting! Maybe it's just a window sizing bug then. Are you all on MacOS 14?

Quite interesting... so this verifies that it is not the os code. It is an issue related to Qemu on MacOS.

Ben · Answer 14 · Sat Nov 25 2023 01:14:18 GMT+0800 (China Standard Time)

macOS Sonoma 14.1.1

Latest stable QEMU build also has the first 20-ish pixels at the top of the output window hidden by the window's title bar:

Wiktor Zając · Answer 15 · Thu Dec 21 2023 08:34:21 GMT+0800 (China Standard Time)

The line width is different (160, not 80 as the code in post 3 assumes), and the first line is invisible. If you change the function to
#[no_mangle]
pub extern "C" fn _start() -> ! {
    let vga_buffer = 0xb8000 as *mut u8;

    for (i, &byte) in HELLO.iter().enumerate() {
        unsafe {
            let line_offset: isize = 160 * 2;
            let char_offset_within_line: isize = i as isize * 2;
            let color_offset_within_line: isize = i as isize * 2 + 1;
            let char_offset = char_offset_within_line + line_offset;
            let color_offset = color_offset_within_line + line_offset;


            *vga_buffer.offset(char_offset) = byte;
            *vga_buffer.offset(color_offset) = 0xb;
        }
    }

    loop {}
}
You get the first fully visible line
And:
let line_offset: isize = 160 * 24;
gives
Looking at the code of `post 3` I see that it starts writing from column `23`. So yeah, that's the problem. Maybe qemu has an ability to specify different settings for VGA, but it seems that it just doesn't display the `0` line with in the current setup

Works for me, thanks!

M. Yasin Özkaya · Answer 16 · Sat Jan 20 2024 20:39:48 GMT+0800 (China Standard Time)

The line width is different (160, not 80 as the code in post 3 assumes), and the first line is invisible. If you change the function to
#[no_mangle]
pub extern "C" fn _start() -> ! {
    let vga_buffer = 0xb8000 as *mut u8;

    for (i, &byte) in HELLO.iter().enumerate() {
        unsafe {
            let line_offset: isize = 160 * 2;
            let char_offset_within_line: isize = i as isize * 2;
            let color_offset_within_line: isize = i as isize * 2 + 1;
            let char_offset = char_offset_within_line + line_offset;
            let color_offset = color_offset_within_line + line_offset;


            *vga_buffer.offset(char_offset) = byte;
            *vga_buffer.offset(color_offset) = 0xb;
        }
    }

    loop {}
}
You get the first fully visible line

And:
let line_offset: isize = 160 * 24;
gives

Looking at the code of post 3 I see that it starts writing from column 23. So yeah, that's the problem. Maybe qemu has an ability to specify different settings for VGA, but it seems that it just doesn't display the 0 line with in the current setup
Works for me, thanks!

thanks for the solution

NightProg · Answer 17 · Sun Jan 28 2024 16:49:25 GMT+0800 (China Standard Time)

The line width is different (160, not 80 as the code in post 3 assumes), and the first line is invisible. If you change the function to
#[no_mangle]
pub extern "C" fn _start() -> ! {
    let vga_buffer = 0xb8000 as *mut u8;

    for (i, &byte) in HELLO.iter().enumerate() {
        unsafe {
            let line_offset: isize = 160 * 2;
            let char_offset_within_line: isize = i as isize * 2;
            let color_offset_within_line: isize = i as isize * 2 + 1;
            let char_offset = char_offset_within_line + line_offset;
            let color_offset = color_offset_within_line + line_offset;


            *vga_buffer.offset(char_offset) = byte;
            *vga_buffer.offset(color_offset) = 0xb;
        }
    }

    loop {}
}
You get the first fully visible line

And:
let line_offset: isize = 160 * 24;
gives

Looking at the code of post 3 I see that it starts writing from column 23. So yeah, that's the problem. Maybe qemu has an ability to specify different settings for VGA, but it seems that it just doesn't display the 0 line with in the current setup

Thanks that work for me

Матвей Т · Answer 18 · Tue Feb 27 2024 08:00:17 GMT+0800 (China Standard Time)

I have opened this issue: https://gitlab.com/qemu-project/qemu/-/issues/1994

It's an API difference between Sonoma and earlier macOS versions NSView documented in https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-14.

Sonoma set NSView.clipsToBounds to false by default and it was true in earlier versions.

DrDonk seems to he working on it, it will hopefully be in the upstream Qemu soon...

Philipp Oppermann · Answer 19 · Tue Feb 27 2024 14:35:44 GMT+0800 (China Standard Time)

@AtomicGamer9523 Thanks a lot, that is great news!

Матвей Т · Answer 20 · Tue Mar 19 2024 06:29:11 GMT+0800 (China Standard Time)

To anybody that stumbled upon this via a google search or because of a pinned comment, here's a quick rundown:

If you are not on MacOS, this should not affect you
If you are not using Qemu, this should not affect you
If you are on MacOS version 13 and bellow, this should not affect you

Now, if you are on MacOS newer than than version 14, and you are using Qemu, listen up.
There is a window-sizing bug in Qemu that will shift text up, preventing you from being able to see some of it.
It is fixed in Qemu 9.0. Bellow are package managers and latest version of Qemu available:

Homebrew (9.0.0)
MacPorts (9.0.0)

Edit: The package managers have updated their packages. Both of them are now up to date. To fix the big, just update Qemu!

Philipp Oppermann · Answer 21 · Tue Apr 30 2024 22:48:32 GMT+0800 (China Standard Time)

Looks like both homebrew and macPorts provide v0.9 now, do I see that right?

Матвей Т · Answer 22 · Wed May 01 2024 02:59:30 GMT+0800 (China Standard Time)

Looks like both homebrew and macPorts provide v0.9 now, do I see that right?

Correct, updating my comment.

Edit: Is it safe to close this issue as completed ?

Philipp Oppermann · Answer 23 · Wed May 01 2024 04:20:05 GMT+0800 (China Standard Time)

Great! Yes, I think we can close this then. I'll keep it pinned for a while, so it should still be visible enough.