Created attachment 122674 [details] kernel boot log. Hardware: Benq Joybook R23E (really old laptop I got gifted recently) Arch Linux (x86), Linux 4.4.5. If I boot with viafb disabled, starting X freezes the whole system. Xorg.0.log doesn't get a chance to be written to disk. If I boot with viafb enabled, it's fine. Therefore I suspect some initialization (or modesetting?) is done properly by viafb, but openchrome driver can't do it on its own. I attach log of 0.3.3, 0.4.0 (before release, built last evening due to testing request), and kernel boot (w/viafb enabled). Note that this problem was already present in 0.3.3.
Created attachment 122675 [details] Xorg log on 0.4.0 (git)
Created attachment 122676 [details] Xorg log on 0.3.3
(In reply to Roc Vallès Domènech from comment #0) Hi Roc, > Created attachment 122674 [details] > kernel boot log. > > Hardware: Benq Joybook R23E (really old laptop I got gifted recently) > > Arch Linux (x86), Linux 4.4.5. > > If I boot with viafb disabled, starting X freezes the whole system. > Xorg.0.log doesn't get a chance to be written to disk. > > If I boot with viafb enabled, it's fine. Therefore I suspect some > initialization (or modesetting?) is done properly by viafb, but openchrome > driver can't do it on its own. > > I attach log of 0.3.3, 0.4.0 (before release, built last evening due to > testing request), and kernel boot (w/viafb enabled). > > Note that this problem was already present in 0.3.3. Thank you very much for testing the newly released OpenChrome Version 0.4.0. 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. It is definitely okay to compare how OpenChrome Version 0.4.0 fares against Version 0.3.3, but just to make it clear to other people reading this post (Roc, I am not criticizing you or being hostile to anyone, just for the record.), I will not maintain or fix any bugs with Version 0.3.3 since it is really broken, and all development and bug fixing efforts will center around Version 0.4.x and newer versions from now on. Just to summarize the issue, this is my understanding of the bug you are reporting. - 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. Obviously, at this point, I do not know the exact cause of the bug, but I think your speculation that OpenChrome is not initializing all the internal registers on its own and viafb happened to be doing this for OpenChrome, is probably reasonable. 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. Based on my own testing, connecting the RCA video output to a TV caused a boot time hang, and I assume the result is similar with S-Video. 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). I only got a commit privilege for freedesktop.org OpenChrome repository around February 9th, 2016, and had to concentrate on fixing DVI to VGA adapter screen detection problem, removing "known device table," and getting rid of OpenChrome legacy mode setting code for the past 2 months. Personally, I will like to pad myself in the back for your K8N800 chipset's LCD detection working correctly based on what I see in the Xorg.0.log you have uploaded. When I removed the infamous "known device table" the previous developers were using, it definitely broke the LCD detection for some people. VIA does use a fairly low tech way to communicate from the firmware to the device driver the existence of an LCD panel and its panel resolution. I have to use this since many LCD panels do not have an I2C bus for automatic detection, and this is probably why your panel is working in the first place. I am "trying to" take several days off from analyzing what is going on inside OpenChrome since, I have to admit, working on fixing OpenChrome has really consumed my life for the past 2 months. I will be studying how VIA initializes the IGP, and hope to feedback what I learned from it into OpenChrome moving forward. Over the next few weeks, I will be rewriting the display detection portion of the code completely since the previous developers did not do a good job of allocating display resources and outputs (This is why they resorted to that infamous "known device table" I have discussed, but even that has many problems. This is why I need to rewrite the display detection portion.). In that process, I expect to improve the display initialization code, so that it will eventually fix the bug you reported. 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.
I meant to say, "pat myself on the back." I guess I should not be posting a message when I am a little tired . . .
> 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.
Hi Roc, I have not necessarily made fixes to specifically fix your bug, but I have made number of fixes to how the Chrome IGP is initialized, so it will be nice if you can test out the code without the viafb you are asking for. Even if the code does not work, it will be nice if it can run to the point where you can capture Xorg.0.log. If the code does not work, then I may have to make riskier changes to the FP (Flat Panel) support code that may cause more problems in the short term. The thing is, some portions of the FP code have not been updated for about 12 years, and it is very difficult to obtain old Chrome IGP laptops for testing purposes.
Hi Roc, Just for your reference, also refer to Bug 95420 as well. It is sort of relevant to those using Linux 4.5 or later.
Alas, my device is now dead. I opened it recently for something basic, and it stopped working afterwards; I have no idea why (did a lot of debugging). I'm paranoid that dumping its bios with flashrom (which I did before powering off and opening it at all) screwed the EC up, but I have no idea how to fix that either. Left it without battery for weeks but it didn't seem to help. When I have time and the inclination, I will try and really open (not just HDD/ram/etc trapdoors but whole thing), which is more painful than it should be, really. When I do, I'll try to locate/remove CMOS battery and such to see if that gets me anywhere in resurrecting it. Until them and if it works, I'm not able to test anything.
(In reply to Roc Vallès Domènech from comment #8) Hi Roc, > Alas, my device is now dead. > > I opened it recently for something basic, and it stopped working afterwards; > I have no idea why (did a lot of debugging). I'm paranoid that dumping its > bios with flashrom (which I did before powering off and opening it at all) > screwed the EC up, but I have no idea how to fix that either. Left it > without battery for weeks but it didn't seem to help. > > When I have time and the inclination, I will try and really open (not just > HDD/ram/etc trapdoors but whole thing), which is more painful than it should > be, really. When I do, I'll try to locate/remove CMOS battery and such to > see if that gets me anywhere in resurrecting it. > > Until them and if it works, I'm not able to test anything. Sorry hear about that. I will keep the bug open for the foreseeable future. I hope you can get your laptop working again.
Feel free to reopen the bug if you get the hardware working again. You will like to clean memory module contacts and / or try a different AC adapter (i.e., third party AC adapter with interchangeable power jacks). Just for the record, OpenChrome DDX runs on K8M800 chipset, but the configuration I tested has only VGA (i.e., no flat panel).
I'll be sure to give it a try if I ever manage to make the device work again.
Your issue sounds fairly similar to Bug 104438. It is also with K8N800 chipset. Just for the record, I have improved the code to the point where I can get KN400 and VN800 chipsets to not only recognize FP, but also handle standby resume. Furthermore, I have confirmed this with both OpenChrome DDX UMS code and upcoming OpenChrome DRM KMS code. The laptop tested were Averatec 3250 laptop (KN400 chipset) and NeoWare m100 mobile thin client (VN800 chipset). That being said, for Averatec 3250 laptop, you need to follow the instructions explained here. https://bracecomputerlab.com/2018/04/29/figuring-out-how-to-get-averatec-3250-laptop-to-handle-standby-resume-on-linux-workaround-accidentally-discovered/ I think K8N800 chipset has similar hardware to VN800 chipset, so the bleeding edge code "should" work (at least in theory). In case you want to try again, just for your information, you will need to blacklist viafb and / or vesafb for Linux 4.5 or later. (In reply to Roc Vallès Domènech from comment #11) > I'll be sure to give it a try if I ever manage to make the device work again.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.