Created attachment 128361 [details] xorg log Just compiled and installed openchrome 0.5.0 on lubuntu 16.04 running standard ubuntu 16.04 openchrome driver. wifi and display was working fine. But after updating to 0.5.0 wifi was not working anymore and I got error message in syslog: b43-phy0 ERROR: Microcode not responding tarmo@hp2133:~$ dmesg|grep b43 [ 35.272196] b43-phy0: Broadcom 4312 WLAN found (core revision 15) [ 35.315896] b43-phy0: Found PHY: Analog 6, Type 5 (LP), Revision 1 [ 35.315919] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2062, Revision 2, Version 0 [ 51.716099] b43-phy0 ERROR: Microcode not responding [ 51.716117] b43-phy0 ERROR: You must go to http://wireless.kernel.org/en/users/Drivers/b43#devicefirmware and download the correct firmware for this driver version. Please carefully read all instructions on this website. tarmo@hp2133:~$ sudo lshw -numeric -C display *-display UNCLAIMED description: VGA compatible controller product: CN896/VN896/P4M900 [Chrome 9 HC] [1106:3371] vendor: VIA Technologies, Inc. [1106] physical id: 0 bus info: pci@0000:01:00.0 version: 01 width: 32 bits clock: 66MHz capabilities: pm agp agp-3.0 vga_controller bus_master cap_list configuration: latency=64 mingnt=2 resources: memory:d0000000-d7ffffff memory:fc000000-fcffffff memory:fbff0000-fbffffff tarmo@hp2133:~$ dmesg | grep -e agp -e drm [ 3.408858] Linux agpgart interface v0.103 [ 3.409182] agpgart: Detected VIA P4M900 chipset [ 3.416773] agpgart-via 0000:00:00.0: AGP aperture is 128M @ 0xf0000000 tarmo@hp2133:~$ grep openchrome /var/log/Xorg.0.log [ 41.386] (==) Matched openchrome as autoconfigured driver 0 [ 41.386] (II) LoadModule: "openchrome" [ 41.387] (II) Loading /usr/lib/xorg/modules/drivers/openchrome_drv.so [ 41.673] (II) Module openchrome: vendor="http://www.freedesktop.org/wiki/Openchrome/" [ 41.682] (!!) (openchrome 0.5.0 release) tarmo@hp2133:~$ grep rendering /var/log/Xorg.0.log [ 42.493] (EE) AIGLX: reverting to software rendering tarmo@hp2133:~$ tarmo@hp2133:~$ lspci -vvnn | grep -A 9 Network 02:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g LP-PHY [14e4:4315] (rev ff) (prog-if ff) !!! Unknown header type 7f Kernel driver in use: b43-pci-bridge Kernel modules: ssb tarmo@hp2133:~$ uname -r 4.4.0-53-generic
We already got such problem, it was reported in http://www.openchrome.org/trac/ticket/288 and solved at some point I believe. Unfortunately above link doesn't work anymore (whole http://openchrome.org/ seems to be down). You can check discussion on this matter in ML archives: https://lists.freedesktop.org/archives/openchrome-users/2009-July/005654.html AFAIR it was openchrome changing reserved bits of some GPU register. Maybe the same bug was re-introduced recently?
Hi, I may not be able to fix the bug until February 2017, but I have also observed the same bug myself. I do own HP 2133 netbook, although the one I got lacks the hard drive bay. It is likely that how I manipulated DVP (Digital Video Port) is likely causing the bug. I do not have much time until end of December, and I will be traveling during most of January. If I decide to bring the HP netbook, then I may be able to fix the bug sooner. I do plan fix this bug prior to OpenChrome Version 0.6 release.
Hi, Thanks for your answer. I suppose you don't need any more info, if you can repeat the problem, so I'll revert back to old driver. There is also a following error in xorg.0.log: (EE) open /dev/dri/card0: No such file or directory Is this somehow related to this error? This driver feels slower in viewing video than via closed source driver. Is this driver drm capable with this card? This old laptop with slow processor is not capable of software rendering.
(In reply to talindva from comment #3) Hi talindva, > Hi, > Thanks for your answer. I suppose you don't need any more info, if you can > repeat the problem, so I'll revert back to old driver. > > There is also a following error in xorg.0.log: > (EE) open /dev/dri/card0: No such file or directory > Is this somehow related to this error? This driver feels slower in viewing > video than via closed source driver. Is this driver drm capable with this > card? This old laptop with slow processor is not capable of software > rendering. Sorry for this bug triage to take so long. I have had many personal obligations other than developing OpenChrome between November to December 2016, so I have had relatively little time to fix bugs. Plus, I was investing more time in developing drm-openchrome, so this took away time from OpenChrome DDX development. This bug is one of the two bugs holding up the release of OpenChrome Version 0.6, so I will like to fix it soon. I did bisecting, and it appears that Version 0.5.151 and 0.5.152 work fine with Broadcom wireless LAN, but seems to fail with Version 0.5.153 often. (although not always, and I do not like this kind of a situation) https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=6a0476bc3aaca391169d752c0220e4ffe615446b (Version 0.5.151) https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=9243d288410857a8c38d11c391af2734d8d482cf (Version 0.5.152) https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=158ea17e8c0e525f9239706449d2d86b7c168c83 (Version 0.5.153) If you can test these 3 versions, and see what happens on your side, that will be highly appreciated. I will say that wireless LAN sometimes appears to work with Version 0.5.153, but most of the time, it does not seem to work. As far as I can tell, the latest version (Version 0.5.175) will disable the Broadcom wireless LAN in question as well. Note that I can really writing this e-mail from HP 2133 netbook. In order to do bisecting, this is how I did it. (Please note that I am not a Git expert, so I am only stating the stuff I know.) From the master branch, $ git checkout 6a0476bc3aaca391169d752c0220e4ffe615446b will bring back Version 0.5.151. From here, regenerate the compilation script, compile, and install OpenChrome. To get Version 0.5.152 back, $ git checkout 9243d288410857a8c38d11c391af2734d8d482cf will bring Version 0.5.152 back. This one is for Version 0.5.153. $ git checkout 158ea17e8c0e525f9239706449d2d86b7c168c83 To get back to the head of master branch, $ git checkout master Remove the "$" character when entering the command into the terminal emulator. I will say that you should always do a cold boot (i.e., shut down the computer every time rather than restarting the computer) since the Broadcom firmware seems to stay with the hardware if you do a warm boot .(i.e., restart) While I will like to fix this bug soon, I may not have access to it until early February 2017, so you may have to help me do the remote testing of the code. Regarding how this bug will be solved, very likely I will need to not enable DVP (Digital Video Port) blindly since it appears that the pins for DVP are dual use pins with PCI Express for 2 chip type VIA Technologies chipsets with PCI Express support. (i.e., P4M890, K8M890, and P4M900 / VN896 / CN896) Since the Broadcom wireless LAN in question uses PCI Express, this is likely the root cause of why the wireless LAN chip fails.
I will also note that I used the open source version of wireless LAN device driver that required some effort in installing the device driver. I did notice that wireless LAN was not working while ago, but I have had much time in playing around with this netbook due to the particular unit I have did not come with a hard drive caddy. As a temporary solution, I used a USB wireless LAN dongle to access the network, so figuring out the network problem was not a real high priority at the time. Also, the VN896 chipset's specification (i.e., data book) not being public at all has also hurt the development effort. So far, the only information I was able to gather online was various laptop mainboard schematics that has given me some idea of how VIA Technologies handle the multiplexed DVP (Digital Video Port) / PCI Express pins, but I still have some doubts on how they really work. In my opinion, OpenChrome is a troubled project (this was well documented by Phoronix), and even with my 1+ year of development effort, it is still so. (I am willing to admit this even though I have made numerous improvements to OpenChrome and also resuming the development of drm-openchrome abandoned by the previous developer.) Previously, the code was not initializing the DVP pins very well, so the code was changed to take care of it within OpenChrome. However, due to not having access to VN896 chipset data book, I did not realize that touching DVP0 / 1 (sometimes it is called DVP1 / 2) will mess up PCI Express. That's my honest explanations on why this regression happened in the first place. Regarding the solution to the problem, I am not sure at this point, but first I will need to truly comprehend and 100% reproduce the bug before I worry about this.
In the older OpenChrome code, many register bits were being initialized by the BIOS. However, this is a problem one wants OpenChrome to work properly with standby resume, especially from STR. (Suspend to RAM or ACPI S3 State) This is the main reason why OpenChrome started to initialize the register bits in the first place. In many cases, important register bits go off when resuming from STR. I got into OpenChrome development since I could not stand standby resume not working very well. That being said, I still have not found good solutions to the standby resume related bugs I see with OpenChrome, especially with VN896 chipset.
I did more testing, and I will also note that this Broadcom BCM4311 appears rather erratic. Even when using OpenChrome Version 0.5.151, sometimes WLAN is not available. I manipulated 3C5.1E and 3C5.2A registers, but when BCM4311 is working, it has no effects on it. Only register bits that can turn off the screen are 3C5.2A[1:0] where if you set these to 00, this will turn off the screen since these bits appear to control DVP1. (DVP1 is multiplexed with PCIe Rx lane 8 through 15) At this point, it is possible that I will put off dealing with this problem since I am having serious issues predictably reproducing the bug. In the worst case, I will treat this problem as a "not my bug" situation.
Okay, I did more testing, and it appears that Broadcom BCM4311's WLAN works reliably with OpenChrome Version 0.4.128. I will try to narrow down which patch level introduced the bug since it is less than reliable with Version 0.4.151, and doesn't work at all with the latest Version 0.5.175. If you can also perform bisecting, that will be nice.
Please try Version 0.5.180 or commit 0ea654c1d0a786b2392773ac33b2b7adc556a947. https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=0ea654c1d0a786b2392773ac33b2b7adc556a947 This version resolves the bug temporarily. I moved my main development hard drive (40 GB) to HP 2133 Mini-Note, and did bisecting of the code. It took a while, but I finally figured out which commits caused this bug. The changes made to the code between Version 0.4.129 and 0.4.130 "broke" your Broadcom PCIe WLAN. I also have VN896 chipset for my other development laptop (Epic 1314), but this one uses a USB based WLAN card (I believe the card connector has connections to PCIe and USB, but only USB is used for this particular card. The USB WLAN card's chip is made by Ralink.), so I never noticed the breakage. I did confirm that the Broadcom PCIe WLAN of my HP 2133 is now working. I will come up with a permanent solution over the next few weeks. This will likely involve the probing of the pin strapping to determine the FP type (12 bit vs. 24 bit) in order to decide which drivers to turn on. This is somewhat tricky since VIA Technologies never made their early PCI Express generation chipset (P4M890 / K8M890 / P4M900) documents public, but I have obtained enough information here and there that I think I can pull this one off. Thank you very much for reporting the bug since I never noticed the bug, and I wanted to come up with a fix so that I can get the code ready for OpenChrome Version 0.6. The promised permanent fix will be incorporated prior to the Version 0.6 release candidate testing period.
Since you are using Lubuntu, you will still need to install b43-fwcutter and firmware-b43-installer. At least these are the modules for Lubuntu 12.04 and Broadcom BCM4311. Since you appear to have BCM4312, firmware-b43-installer may not work for you. The names might be slightly different for Lubuntu 16.04, but you probably get the idea. You can use Synaptic Package Manager or apt-get from the terminal. If you want to close the bug, you can do so, or I can close the bug for you.
Fixed by commit 1f78989. https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=1f7898969a38f3e350871168338deb1dfbb1cc18 Version 0.5.182 fixes the bug.
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.