[Openchrome-devel] [Bug 94797] K8M800/K8N800 (unsure which): OpenChrome crashes if viafb is not enabled

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94797

--- Comment #5 from Roc Vallès Domènech <vallesroc at gmail.com> ---
> Since there are only so many VIA hardware I can get a hold of, as a
> developer, I do appreciate the feedback from the users of OpenChrome.

And I really do appreciate there's some life to OpenChrome again :)

> 0.3.3

Only mentioned (and attached log because why not) to let you know the issue was
present on 0.3.3 too. My old plan was to try 0,3.4 and open a bug report if it
didn't work there. As that version didn't and won't happen, I instead reported
it now.

> - X Server boots fine with OpenChrome Version 0.4.0 if viafb is enabled 
> - X Server crashes with OpenChrome Version 0.4.0 if viafb is disabled 
> - When X Server crashes, it does not record Xorg.0.log
> 
> Let me know, if I missed something.

So far so good.

> Just for your information, I do know that connecting your laptop's S-Video
> output to a TV will likely cause a boot time hang, and if you happened to
> have an S-Video capable TV, it will be nice if you can test it.

No TVs at hand sadly. I moved and on my new location I only have a newish,
awesome screen (Dell u2413) that doesn't even do VGA. This happened over a year
ago; for a few month I only had this old laptop, which despite really old, was
really useful to me at the time. Nowadays, I keep it on a side and use it as
ssh terminal to a few places (still useful!), and occassionally have a
webbrowser open, to read docs or to write the occassional OpenChrome bug report
;)

>     I only "discovered" this in the past week or so, but as far as display
> initialization is concerned, viafb source code is probably the most complete
> source that documents the hardware registers of VIA UniChrome and Chrome9
> IGPs since VIA never released hardware programming documents other than
> CX700 / VX700, VX800, VX855, and VX900 to the public (i.e., without
> requiring an NDA).

Did try not to clutter the original bug with the extra information, but as I
see it might help, why not. At some point in the past, next to the Arch Linux
lvm-on-luks partition, I used to have a netbsd6.1 which I used more than Linux.
NetBSD has a via chrome framebuffer in its kernel, too. Building a custom
kernel was necessary to enable it (and other stuff I needed). I believe there
was the same issue with X, although I can't remember.

At some point, I updated to CURRENT (pre-7.0 at the time), and while it still
worked, backlight would stay on when idling, so I had to give up on it. I
didn't want to reinstall netbsd6, so I tried OpenBSD (5.6 at the time?), which
sadly had the same issue.

Right now, in the spare partition, I do have ReactOS 0.4.0 (as a curiosity),
which has its assortment of issues, and where official VIA drivers for Chrome
do not work; I tried; VESA is all that works. Intend to try minix3.4 once they
release it; qemu can't install the current rc2, and the only other way, as the
cd drive in this thing is dead, is PXE; they'll supposedly have a pxe method
with builtin install ramdisk available by release or so.

> I expect to improve the display initialization code, so that it will eventually fix the bug you reported.

Great.

> Please do not expect immediate results since releasing OpenChrome Version
> 0.4.0 took a lot longer than I originally expected, and it is very difficult
> to sometimes comprehend the code the previous developers wrote.

No problem, as it does still work w/viafb's help. Just say the word in this bug
report if you need me to build and test git at any given time.

We could even arrange some sort of syncronous "send logs to network" setup to
better debug the crash, if we need to.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/openchrome-devel/attachments/20160402/27ddb023/attachment.html>