Guest fosser2 Posted February 24, 2013 Report Share Posted February 24, 2013 (edited) Debugging purposes, only... ;) That's what I thought thanks :) EDIT: I'm attempting to figure out where the libcamera drivers you guys are using originated from. If you could point me to them it would be a great help. Thanks! EDIT2: Does the vega have hdmi and how is that working? I switched over to your libs yesterday and I lost the video portion of hdmi (I still have audio over hdmi). EDIT3: After renaming hwcomposer.tegra_v0.so to hwcomposer.tegra.so hdmi is back and working. I'm wondering if you guys have that lib named incorrectly (just a heads up) Edited February 25, 2013 by fosser2 Link to comment Share on other sites More sharing options...
Guest ejtagle Posted February 26, 2013 Report Share Posted February 26, 2013 That's what I thought thanks :) EDIT: I'm attempting to figure out where the libcamera drivers you guys are using originated from. If you could point me to them it would be a great help. Thanks! EDIT2: Does the vega have hdmi and how is that working? I switched over to your libs yesterday and I lost the video portion of hdmi (I still have audio over hdmi). EDIT3: After renaming hwcomposer.tegra_v0.so to hwcomposer.tegra.so hdmi is back and working. I'm wondering if you guys have that lib named incorrectly (just a heads up) libcamera originated from android 2.2. Was severely modified by me to port it to android 3.0, then 4.0/4.1/4.2 ... In the way, I added some code taken from luvview, spcaview... Refactored out everything several times to make it more compatible... - luvcview: Sdl video Usb Video Class grabber © 2005,2006,2007 Laurent Pinchart && Michel Xhaard - spcaview © 2003,2004,2005,2006 Michel Xhaard - JPEG decoder from http://www.bootsplash.org/ © August 2001 by Michael Schroeder, <[email protected]> - libcamera V4L for Android 2.2 © 2009 0xlab.org - http://0xlab.org/ © 2010 SpectraCore Technologies Author: Venkat Raju <[email protected]> Based on a code from http://code.google.com/p/android-m912/downloads/detail?name=v4l2_camera_v2.patch - guvcview: http://guvcview.berlios.de Paulo Assis <[email protected]> Nobuhiro Iwamatsu <[email protected]> Regarding HDMI and the hwcomposer, i wrote a wrapper to be able to use the old hwcomposer with the 4.2 series. That is why you found the _v0.so file. That module is loaded by our wrapper. Another way to do it is to forward port the old hwcomposer support from 4.1 to 4.2... Link to comment Share on other sites More sharing options...
Guest fosser2 Posted February 28, 2013 Report Share Posted February 28, 2013 ejtagle, I'm wondering what happens when you guys have hdmi plugged into your tablet and you try to sleep it. Our tablet surfaceflinger crashes because of gralloc.tegra.so. Was gralloc patched also for 4.2? Below is the crash. ADB: http://pastebin.com/v15a0WGP SERIAL: http://pastebin.com/dx0Xb23Y I believe it is a lib issue related to the gralloc. As for the IRQ issue in the serial file, I believe this is caused from some i2c settings. I'm not overly concerned about that right now because I'm pretty sure they are 2 separate issues. Lastly HDMI does output as well as hdmi audio. Just likes to crash when someone attempts to sleep w/ hdmi plugged in. Link to comment Share on other sites More sharing options...
Guest ejtagle Posted March 1, 2013 Report Share Posted March 1, 2013 ejtagle, I'm wondering what happens when you guys have hdmi plugged into your tablet and you try to sleep it. Our tablet surfaceflinger crashes because of gralloc.tegra.so. Was gralloc patched also for 4.2? Below is the crash. ADB: http://pastebin.com/v15a0WGP SERIAL: http://pastebin.com/dx0Xb23Y I believe it is a lib issue related to the gralloc. As for the IRQ issue in the serial file, I believe this is caused from some i2c settings. I'm not overly concerned about that right now because I'm pretty sure they are 2 separate issues. Lastly HDMI does output as well as hdmi audio. Just likes to crash when someone attempts to sleep w/ hdmi plugged in. tegra_fb_blank , called from fb_blank, called from sys_ioctl ... I think, just guessing here, that from userspace we are getting a ioctl(fd, FBIOBLANK, fb_blank); If you are using the hwcomposer wrapper i wrote, comment out all the contents of the tegra2_blank function, and just leave the return 0; last line Seems something is trying to blank the hdmi output.... and seems the operation is unsupported. That crashes the kernel video subsystem, that in turn crashes gralloc... Link to comment Share on other sites More sharing options...
Guest ejtagle Posted March 2, 2013 Report Share Posted March 2, 2013 Regarding video, I found out that the hwcomposer wrapper i wrote was causing some trouble when screen is turned off. Specifically, it did not disable vsync interrupts, so the linux kernel tegra video subsystem started to complain about syncpoints timing out... I have fixed the hwcomposer module so now it disables vsync while screen is off. I do suspect that this could also be the cause of some SODs... Please, test and report. At least, works for me and removes all errors related to syncpoints and most errors related to gralloc.hwc.rar Link to comment Share on other sites More sharing options...
Guest ejtagle Posted March 2, 2013 Report Share Posted March 2, 2013 Regarding video, I found out that the hwcomposer wrapper i wrote was causing some trouble when screen is turned off. Specifically, it did not disable vsync interrupts, so the linux kernel tegra video subsystem started to complain about syncpoints timing out... I have fixed the hwcomposer module so now it disables vsync while screen is off. I do suspect that this could also be the cause of some SODs... Please, test and report. At least, works for me and removes all errors related to syncpoints and most errors related to gralloc. I left the p10an01 on, so it tries to enter lp1 suspend mode. It did, as expected. 10 hours later, i pressed the physical back button, and the tablet did not wake up (this is expected behaviour, the tablet should not wake up with the back button, as that would mean it is not in deep sleep. The only physical button that is able to wake from deep sleep is the power button. Now i pressed the power button and the tablet woke up without issues. The kernel log confirms the device was in deep sleep :) -- So, maybe we have fixed the SOD issues... Link to comment Share on other sites More sharing options...
Guest Scanno Posted March 2, 2013 Report Share Posted March 2, 2013 (edited) I left the p10an01 on, so it tries to enter lp1 suspend mode. It did, as expected. 10 hours later, i pressed the physical back button, and the tablet did not wake up (this is expected behaviour, the tablet should not wake up with the back button, as that would mean it is not in deep sleep. The only physical button that is able to wake from deep sleep is the power button. Now i pressed the power button and the tablet woke up without issues. The kernel log confirms the device was in deep sleep :) -- So, maybe we have fixed the SOD issues... Thanks, I am building a new version of CM10.1 with the new hwc. I will post it as alpha13 (lucky number hopefully). Edited March 2, 2013 by Scanno Link to comment Share on other sites More sharing options...
Guest Scanno Posted March 2, 2013 Report Share Posted March 2, 2013 Sadly the new hwcomposer did not solve the SOD problem Link to comment Share on other sites More sharing options...
Guest fosser2 Posted March 3, 2013 Report Share Posted March 3, 2013 (edited) Ejtagle, I tried out the new HWC and although hardware decoding still works I'm having the same issues with HDMI. ADB: http://pastebin.com/wJkasPxp (at 16:10:01.341 I pushed sleep button) Serial: http://pastebin.com/t11uHjiw Scanno: we seem to have sleep working (without HDMI) on our tablet. From this log you can see that my tablet enters and exits LP1 as it should. We are having other users tablets SOD though. Their last_kmsg files look similar to the following. http://pastebin.com/9xd96dVz Edited March 3, 2013 by fosser2 Link to comment Share on other sites More sharing options...
Guest ejtagle Posted March 3, 2013 Report Share Posted March 3, 2013 (edited) Well, here we go again trying to fix the SoD... Added to the previous hwc fixes (that also seem to have fixed issues on screen not repainting), there was a problem with the wifi driver (ar6002) and our configuration and handling of the sdhci slot where it is connected. I found out that the chipset was being powered down by one of our drivers (at the linux kernel level) while the system was entering deep suspend. Also, the driver itself was resseting the chipset when the system returned from deep sleep.. And the sdhci linux kernel component was powering down the sdhci bus. All the above thing resulted in a complete reinitialization of the wifi card at resume, but that sometimes clashed with the ar6002 driver, that was expecting the card to remain powered ... Result: sometimes the system just crashed at resume... Because the ar6002 driver was sending commands to a dead bus and card, and waiting for responses... The proper thing to do was (and that is exactly what is done on other platforms): -Keep the wifi card in WoW mode (powered up), WoW mode will wake the device if some traffic targeting the device is received -Keep the sdhci bus powered, othewise, the card cant wake the system -Do not implement workarounds at the wifi driver level for things that are already fixed in the kernel -Do not remove power to the card while suspended. Android, if asked to, will load and unload the driver when enabling and disabling wifi. When the driver is unloaded, the wifi card is powered down I am including the patched kernel, with the required .config file... Some changes were required, some configs were missing... Also included de patched ar6002 driver sources (i removed the workarounds that are not required anymore)rel-15r7.rarwlan_wow.rar Edited March 3, 2013 by ejtagle Link to comment Share on other sites More sharing options...
Guest ejtagle Posted March 3, 2013 Report Share Posted March 3, 2013 (edited) Ejtagle, I tried out the new HWC and although hardware decoding still works I'm having the same issues with HDMI. ADB: http://pastebin.com/wJkasPxp (at 16:10:01.341 I pushed sleep button) Serial: http://pastebin.com/t11uHjiw Scanno: we seem to have sleep working (without HDMI) on our tablet. From this log you can see that my tablet enters and exits LP1 as it should. We are having other users tablets SOD though. Their last_kmsg files look similar to the following. http://pastebin.com/9xd96dVz This seems to be a bug in the gralloc and/or surfaceflinger. I am guessing here, but seems gralloc is returning bogus values when asked tor the HDMI screen resolution, when it still not read from the display. That seems to be causing a division by 0 exception on surfaceflinger... I guess that to fix this problem, a patch to surfaceflinger is required (or a wrapper to gralloc) PD: After further investigation, the problem seems to be a race condition between gralloc and linux kernel video subsystem. When resuming, all HDMI displays are autodetected. But, that takes some time. Gralloc tries to read and set capabilities before the HDMI display is detected, and so, it gets an error and a 0x0 display. Then it tries to use that display... and crashes... This seems to be an actual tegra video subsystem bug... Edited March 4, 2013 by ejtagle Link to comment Share on other sites More sharing options...
Guest ejtagle Posted March 4, 2013 Report Share Posted March 4, 2013 I will also post here my latest bluetooth attempts. On the ui, everything seems to work, but, i was unable to make a bt connection, so guessing something is still missing... Nevertheless, it will be interesting to know if someone is able to actually use the bluetooth... I am attaching 2 archives: >The first one contains my latest libbt-vendor, that is required so bluedroid knows how to talk to the hci layer of the linux kernel >The 2nd one is the required files that must be installed in /etc/bluetooth so the the libbtvendor is able to properly configure the bluetooth chipsetetc.rarlibbt-vendor.rar Link to comment Share on other sites More sharing options...
Guest fosser2 Posted March 4, 2013 Report Share Posted March 4, 2013 (edited) This seems to be a bug in the gralloc and/or surfaceflinger. I am guessing here, but seems gralloc is returning bogus values when asked tor the HDMI screen resolution, when it still not read from the display. That seems to be causing a division by 0 exception on surfaceflinger... I guess that to fix this problem, a patch to surfaceflinger is required (or a wrapper to gralloc) Does this crash happen on the vega too like I posted? PD: After further investigation, the problem seems to be a race condition between gralloc and linux kernel video subsystem. When resuming, all HDMI displays are autodetected. But, that takes some time. Gralloc tries to read and set capabilities before the HDMI display is detected, and so, it gets an error and a 0x0 display. Then it tries to use that display... and crashes... This seems to be an actual tegra video subsystem bug... I don't actually try to resume my tablet when this crash happens. As soon as I put it to sleep while on hdmi is when everything errors. It never makes it into LP1 while on hdmi. Edited March 4, 2013 by fosser2 Link to comment Share on other sites More sharing options...
Guest ejtagle Posted March 4, 2013 Report Share Posted March 4, 2013 (edited) Does this crash happen on the vega too like I posted? I don't actually try to resume my tablet when this crash happens. As soon as I put it to sleep while on hdmi is when everything errors. It never makes it into LP1 while on hdmi. Yes, i get exactly the same error... If HDMI is enabled and the tablet tries to enter suspend, i get the same crashing gralloc.... Logcat is very similar to yours. I have tracked the issue to /drivers/video/tegra/dc/ext/dev.c ... They disable dcs on suspend, and reenable them on resume. The problem is that gralloc is unaware of those disablings, so, when they try to redetect hdmi, and the dcs are disabled, they get 0 values and that crashes gralloc... It is a plain race condition between android framework and the suspend mechanism... Not synced at all... This message is the one giving some clues... NvGrPost: Failed, TEGRA_DC_EXT_FLIP 6 6= ENXIO . I partially reverse engineered gralloc, and found out this ioctl is a part of a secuence that tries to get hdmi resolution, copies output to hdmi, flips dcs to display into main ... I dont know why, but android is accessing the screen even when it is suspended... gralloc should be discarding all screen access when the video subsystem is suspended... but it does not. And that seems to be the cause of gralloc crashes... Seems the only way to fix this is to also create a gralloc wrapper... Edited March 4, 2013 by ejtagle Link to comment Share on other sites More sharing options...
Guest Scanno Posted March 4, 2013 Report Share Posted March 4, 2013 I will also post here my latest bluetooth attempts. On the ui, everything seems to work, but, i was unable to make a bt connection, so guessing something is still missing... Nevertheless, it will be interesting to know if someone is able to actually use the bluetooth... I am attaching 2 archives: >The first one contains my latest libbt-vendor, that is required so bluedroid knows how to talk to the hci layer of the linux kernel >The 2nd one is the required files that must be installed in /etc/bluetooth so the the libbtvendor is able to properly configure the bluetooth chipset Great I will have a go at this. The old Bluetooth stuff is that still needed or can in remove that? I mean the hciattach. Is that now included? Link to comment Share on other sites More sharing options...
Guest ejtagle Posted March 4, 2013 Report Share Posted March 4, 2013 Great I will have a go at this. The old Bluetooth stuff is that still needed or can in remove that? I mean the hciattach. Is that now included? The hciattach functionality is now included in libbt-vendor, We should need no part of bluez... Link to comment Share on other sites More sharing options...
Guest Scanno Posted March 4, 2013 Report Share Posted March 4, 2013 The hciattach functionality is now included in libbt-vendor, We should need no part of bluez... OK i will remove all the old stuff and implement lbbt-vendor and put the files you posted in /etc/bluetooth Lets see how far we can get. Do not know when i have time for this hopefully i can get some stuff done tonight. Link to comment Share on other sites More sharing options...
Guest ejtagle Posted March 5, 2013 Report Share Posted March 5, 2013 (edited) Does this crash happen on the vega too like I posted? I don't actually try to resume my tablet when this crash happens. As soon as I put it to sleep while on hdmi is when everything errors. It never makes it into LP1 while on hdmi. fosser2: Could you please try the attached hwc to see if the hdmi crashes continue ? - What i did was to disable the hwc when the screen is turned off. This seems to cure the crashes. At the same time, i get a "Cannot lock buffer" error on gralloc, but, it does not crash, and, as soon as screen is turned on again, it resumes working without issues... or at least, that is what i believe... To all the other people... Please do not integrate this hwc to any rom.. not yet... It still does not work properly. The problem i see is that when the system is turning off the screen, it still tries to render to a turned off video subsystem. When there is no hdmi connection, besides getting some flip errors, no other strange or harmful thing happens. But, when HDMI is plugged in, there is an extra thing causing trouble... The mirroring operation that copies framebuffer to HDMI bombs gralloc. I still have to figure out if the problem is that we are turning off the screen (something that was not implemented in the original hwc), our interrupt emulation, or just the something that was changed by Google at the framework level. I think it can be fixed, though. The attached hwc simply rejects calls when the screen is turned off (that is the difference to the previous hwc... This provents the crashes, but causes other issues... One of them is polluting logcat with hwc errors... But, at least, no more crashes... Really would appreciate testing of this hwc with and without hdmi plugged in... Edit2: the new hwc seems to be working pretty well, at least, it does not crash gralloc when the tablet suspends and HDMI is plugged in.. I am testing it right now... Prper HDMI output, proper video decoding, no crashes and tablet continues resuming from deep sleep without issues.. If today tablet kees waking without issues, i think we could integrate it... :)hwc_v2.rar Edited March 6, 2013 by ejtagle Link to comment Share on other sites More sharing options...
Guest fosser2 Posted March 6, 2013 Report Share Posted March 6, 2013 ejtagle, Sorry, I should get around to testing this soon. I am mid-move as I just got a new job. Thanks for the work and I'm looking forward to testing it! fosser2 Link to comment Share on other sites More sharing options...
Guest ejtagle Posted March 6, 2013 Report Share Posted March 6, 2013 ejtagle, Sorry, I should get around to testing this soon. I am mid-move as I just got a new job. Thanks for the work and I'm looking forward to testing it! fosser2 No problems... I am testing it myself, but i thought it could also solve the problems you have with your port .. ;) Link to comment Share on other sites More sharing options...
Guest fosser2 Posted March 11, 2013 Report Share Posted March 11, 2013 No problems... I am testing it myself, but i thought it could also solve the problems you have with your port .. ;) Well from my tests the "crash" seems to have been cured. Great job with that! I'm not sure if all the i2c issues are lib related or kernel related, my guess is the latter. I guess I'll have to mess w/ my i2c even more... I was able to get display and it slept fine though as you can see from the logs. ADB: http://pastebin.com/deXcMUA6 SERIAL: http://pastebin.com/ZWNEM4k5 Link to comment Share on other sites More sharing options...
Guest fosser2 Posted March 12, 2013 Report Share Posted March 12, 2013 (edited) Scanno, Just wondering if you have built CM10.1 recently, and if so has your system ui crashed? It seems like CM pushed something new that has broken Xoom and similar tegra2 tablets. fosser2 EDIT: nvm I got the issue fixed. You will have to patch your CM10.1 build if you did not already do so. https://github.com/redeyedjedi/android_device_smba_common/commit/e1c3e25c2f19235c7ae8fc7da74aacdd49b739f8 Edited March 13, 2013 by fosser2 Link to comment Share on other sites More sharing options...
Guest ejtagle Posted March 13, 2013 Report Share Posted March 13, 2013 (edited) Well from my tests the "crash" seems to have been cured. Great job with that! I'm not sure if all the i2c issues are lib related or kernel related, my guess is the latter. I guess I'll have to mess w/ my i2c even more... I was able to get display and it slept fine though as you can see from the logs. ADB: http://pastebin.com/deXcMUA6 SERIAL: http://pastebin.com/ZWNEM4k5 What i don't like about your SERIAL log is the unbalanced enable IRQ ... That means something is pretty wrong. I don't have them. It is something related to the screen blanking. I seem to remember that it could be caused by something trying to blank the HDMI output, or perhaps you have enabled console autoblanking at the same time as android managed autoblanking... Disable console autoblanking, just let android manage it. Also, check platform_pwm_backlight_data, specifically the .check_fb function. You MUST ONLY blank the default framebuffer, NOT the HDMI framebuffer.... As it can cause this thing related to unbalanced irqs... Also check your earlysuspend routines for the framebuffers. You dont want to power down the hdmi panel... Edited March 13, 2013 by ejtagle Link to comment Share on other sites More sharing options...
Guest fosser2 Posted March 13, 2013 Report Share Posted March 13, 2013 (edited) What i don't like about your SERIAL log is the unbalanced enable IRQ ... That means something is pretty wrong. I don't have them. It is something related to the screen blanking. I seem to remember that it could be caused by something trying to blank the HDMI output, or perhaps you have enabled console autoblanking at the same time as android managed autoblanking... Disable console autoblanking, just let android manage it. Also, check platform_pwm_backlight_data, specifically the .check_fb function. You MUST ONLY blank the default framebuffer, NOT the HDMI framebuffer.... As it can cause this thing related to unbalanced irqs... Also check your earlysuspend routines for the framebuffers. You dont want to power down the hdmi panel... I'm pretty sure I am only blanking FB1 not FB2 which is hdmi. Our panel file is here. I am hoping you can point me to the "console autoblanking." I would like to make sure I do not have that enabled. I will dig into the pwm backlight data also and report back if that fixes anything. Thanks for the help. fosser2 EDIT: from the looks of it my ".check_fb" function is the same as yours. Edited March 13, 2013 by fosser2 Link to comment Share on other sites More sharing options...
Guest Scanno Posted March 13, 2013 Report Share Posted March 13, 2013 Scanno, Just wondering if you have built CM10.1 recently, and if so has your system ui crashed? It seems like CM pushed something new that has broken Xoom and similar tegra2 tablets. fosser2 EDIT: nvm I got the issue fixed. You will have to patch your CM10.1 build if you did not already do so. https://github.com/redeyedjedi/android_device_smba_common/commit/e1c3e25c2f19235c7ae8fc7da74aacdd49b739f8 I have build it and i had the same problem. I have not had time to investigate the issue. But thanks a lot for the signal and the solution. Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now