Smap after installing Matrox to Ryzen

[TmTFx]

A Ryzen 2400G (with video card integrated) + Nvidia card was booting fine (but working with framebuffer), so I installed a Matrox PCIe G550. After installing it I got SMAP error at the last icon of the boot screen. Disabling SMAP boots fine and I can use Matrox video card as default output.

R1/Beta2 hrev 54154+31

[TmTFx]

KDL messages

[TmTFx]

If you need syslog I took it, but it's 26 screenshots (photos)

[waddlesplash]

Nobody has updated this driver to be SMAP-compliant.

[waddlesplash]

(The syslog photos are unnecessary, the problem is clear from the KDL photo.)

[korli]

TmTFx are you wanting to fix this driver? Here are some tips:

• the s3 driver has somehow been fixed for SMAP: ​https://git.haiku-os.org/haiku/commit/src/add-ons/kernel/drivers/graphics?id=0ff73852d13d60324e101e889cec8c368cab8a93
• at ​https://git.haiku-os.org/haiku/tree/src/add-ons/kernel/drivers/graphics/matrox/driver.c#n362: replace 0 with B_KERNEL_READ_AREA | B_KERNEL_WRITE_AREA
• at ​https://git.haiku-os.org/haiku/tree/src/add-ons/kernel/drivers/graphics/matrox/driver.c#n772: add | B_KERNEL_READ_AREA | B_KERNEL_WRITE_AREA

[TmTFx]

yes, I can try! thank you

[TmTFx]

Premise: I'm not a developer nor I know very much C++ (just bought the book Programming with haiku). I git-cloned haiku and modified matrox driver.c in this way:

• I've modified the line 772 as you suggested
• the line 362 after looking at what is si->use_clone_bugfix I decided to modify it in this way:

B_CLONEABLE_AREA | B_KERNEL_READ_AREA | B_KERNEL_WRITE_AREA, because this condition if (0)sysinfo.kernel_build_date[0]=='J')/*FIXME - better ID version*/

{

si->use_clone_bugfix = 1;

} else {

si->use_clone_bugfix = 0;

}

is always false so I think (si->use_clone_bugfix ? B_READ_AREA|B_WRITE_AREA : 0) would never use B_READ_AREA|B_WRITE_AREA

after those changes I compiled built the iso-anyboot image and tested

It still halts due to SMAP error

[korli]

The SMAP happens on a memcpy call, which should be one of the memcpy after ​https://git.haiku-os.org/haiku/tree/src/add-ons/kernel/drivers/graphics/matrox/driver.c#n605 and ​https://git.haiku-os.org/haiku/tree/src/add-ons/kernel/drivers/graphics/matrox/driver.c#n384

Please try to replace B_READ_AREA with B_KERNEL_READ_AREA in both places.

[TmTFx]

Let me understand, are B_READ_AREA and B_WRITE_AREA deprecated for the drivers? I found other map_physical_memory functions (line 453,502,512). Should I change them (some are card specific, like Millennium I/Mystique)

[korli]

Haiku introduced B_KERNEL_READ_AREA and B_KERNEL_WRITE_AREA, it means that if a kernel driver wants to read some mapped memory, it should use B_KERNEL_READ_AREA. With B_READ_AREA, it would only be readable from userland.

[TmTFx]

Thank you for explanation, I did as you suggested (rows 605 and 384), compiled with newer driver and still have SMAP violation.

[korli]

is the stacktrace the same as in the KDL im ticket?

[TmTFx]

no, it's different, let me attach a screenshot

[TmTFx]

20-05-20

[korli]

it seems now to happen to ioctl().

Have a look at this change to replicate in matrox: ​https://git.haiku-os.org/haiku/diff/src/add-ons/kernel/drivers/graphics/radeon_hd/device.cpp?id=ca11520f4a847a0af14f0eaf9293abddfa444770

[korli]

I pushed a change WIP here: ​https://review.haiku-os.org/c/haiku/+/2762 it might be incomplete.

[korli]

patch proposal

[korli]

any feedback?

[TmTFx]

Replying to korli:

any feedback?

Tried an automated iso (hrev55136 with this patch included) without success still facing smap violation

[korli]

Replying to TmTFx:

Tried an automated iso (hrev55136 with this patch included) without success still facing smap violation

Thanks, do you have a screenshot?

[rudolfc]

Hi, if you want I can take a look at G550 PCIe, I have one over here too. (I wrote the driver largely btw..) also, the cloneable workaround can probably be gone, if I remember correctly that was introduced for an error in BeOS R4.5? It remained there for compat reasons.

Update: Do I need a AMD CPU to get that error btw? I'm normally on Intel. No experience with smap here yet.

[TmTFx]

kdl after patch

[TmTFx]

No mention about Matrox in syslog... Anyway SMAP should be in Intel cpus from Haswell series on (don't know if all cpus support it)

[rudolfc]

Ah, thanks. Just checked my systems: they're too old so I cannot test atm unfortunately.

[korli]

I just pushed an updated patch. Please check again when a new image is built with the patch "Version 3".

[kallisti5]

Keep us posted. This one should likely get squeezed in before we branch R1 / Beta 3

[TmTFx]

With this patch I get no KDL-SMAP violation, it boots and loads all the icons, but then I have blank screens on both outputs

[korli]

An updated patch is now pushed. Please check again when a new image is built with the patch "Version 4".

[TmTFx]

Still no output signal from both connectors after boot icons

[korli]

Something in the syslog maybe? (on the next boot)

[Coldfirex]

So it appears the SMAP issue is resolved, but now its a different booting issue? How does it function using VESA? Are you on Beta 3 now?

[TmTFx]

Vesa is ok, the problem is Matrox driver, I'm not using beta3 I used the patched version built for this particular purpose, and I don't think they upstreamed this version of Matrox driver due to no output at all...

[Coldfirex]

Can you grab the syslog in case it has any extra info?

[TmTFx]

It seems I was (partially) wrong: in a matrox + nvidia configuration failsafe graphics mode boots me to the desktop in a matrox only configuration after boot icons i get blank screen in normal boot and in failsafe graphics mode. After the blank screen it seems that the OS still works underneath as normal (the usb dongle blinks sometimes as it reads or writes) and if I press the power button, the system shuts down gently. How can I save and post the previous boot syslog file?

[TmTFx]

I will investigate this problem with vesa on Thursday or Friday, as it's strange that vesa won't work it could be my fault...

[korli]

if you can safely shutdown the OS, then you can mount the usb dongle in Linux, and find the syslog there.

[X512]

I recently made SMAP fixes for ATI driver (used in QEMU): hrev55211.

[TmTFx]

Syslog nightly patched for matrox

[TmTFx]

This is the syslog it has been asked for

[rudolfc]

Can you please create in ~/config/settings/kernel/drivers/ a file named matrox.settings, and in it have a line : logmask 0xffffffff

and reboot with the matrox driver? This will create the driver's own specific logfile in your home folder, assuming the accelerant does start. Please upload that file here..

Thanks!

BTW: this settings file works for all my drivers, and examples exist, including html docs. For matrox you'll find it here in git: root/src/add-ons/kernel/drivers/graphics/matrox/matrox.settings

[rudolfc]

BTW assigning it to me for now, so I keep updated. Also I can hopefully run a test with these mods on my old CPU to see if that at least still works?

[rudolfc]

So I just tried the latest patchset (4) on my older P4 system with PCIe Matrox G550. The driver works OK without this patchset (testing 32bit), but it also functions OK with this patchset.

So it would seem to me that the patch does not destroy anything.

Looking at the patch: I think I saw in an earlier patchset that the register area mapping also used new flags, but in this set they don't. Could that be a problem? (the registers are accessed from userspace..)

BTW (offtopic I guess) I see two accelerant logfiles appearing when I test BWindowSCreen (uses a clone): one log for the primary accelerant, and one for the (first) clone. Looking all OK.

I'd still like to see an accelerant logfile from the SMAP problematic system..

[rudolfc]

And how about the ROM mirror? that's accessed from userland, but saved to file inside the kerneldriver IIRC.

[rudolfc]

One last thing: this driver does not support DVI output IIRC: please use VGA for testing (if needed via DVI->analog VGA passive adapter.) Both outputs are supported for VGA, if all is right the driver autodetects where the VGA screen is connected and it sends output there. Please don't connect TVout adapters/cables to be sure all is right (since TVout is also supported on these cards).

[TmTFx]

I feel sorry for this but it seems it was only this last suggestion that prevented me to see the desktop. With an analog vga adapter it works, even if it does not retrive the preferred screen size (from edid?) of the monitor and does not list it on available resolutions

[TmTFx]

matrox log

[rudolfc]

Nice! No problem, I'd say. So I'm +2 for updating git with the driver patch V4 then.

About resolutions: I'd have to doublecheck, but I think it depends upon the connector you use: for optimum resolution options, use the connector closest to the system's mainboard: this is the primary DAC output. The other one is the secondary one, which in earlier cards was a seperate chip. This second one has lower capabilities. It can most definately -not- display 1920x1080, I think 1600x1200 or even one lower is the max there.

Anyway, I'll look it up and post that here for you.

[rudolfc]

Looked at the log: ROM access is working in the accelerant, no problem there either.

About the secondary connector: that can also only display 16 and 32bit color, so no 8 or 15bit (you can see that in the log, max DAC freq is reported zero for these depths.

[TmTFx]

Now my configuration has also an nvidia card connected, which is used to show the boot progress icons. If I connect the inner (closest to mainboard) connector I get no output. If I connect the secondary connector I get the output. Now I-ll try removing the nvidia card, but I guess no changes on first connector output.

[rudolfc]

Interesting combination, have that here too, also icons on nvidia, and desktop on MAtrox. Anyhow, I am willing to have a closer look at the matrox driver, looks like indeed DDC is not implemented for instance, and no DVI support. (The primary connector I'll test here then myself as well to see whats happening there: is not related to the nvidia, that I know for sure)

Maybe it would be nice to add those 'options' after all, since Matrox remains a special brand :-)

I guess this ticket can be closed after applying patch v4 to git, and for the internals in the matrox card I think you should open a new ticket. I'll look at that then.

[TmTFx]

I confirm (without nvidia) output for desktop only on second connector (on the first only boot icons). I'll open a new ticket for this. The smap is resolved so I think this ticket can be closed. Thank you

[korli]

patch v4 merged in hrev55483. thanks for the feedback!