Nouveau *experiments* with Android-x86

8953 views
Skip to first unread message

pstglia

unread,
Jun 6, 2014, 4:41:48 AM6/6/14
to andro...@googlegroups.com
Warning: Before you waste your precious time reading this: 
 - I'm just sharing my "findings" (probably already known and obvious for many people) and changes made to drm_gralloc_nouveau;
 - My knowledge is very limited. This means the chances of success are very limited ( 0,00001% in a very optimistic scenario);
 - My "findings" may be totally wrong, so don't take it as absolute truth


PART 1: Technical info

About a week ago, I decided to play with nouveau on Android-x86. I wanted to check if I was able to compile a version including it (just compile - working is another history...)

First of all, I analyzed hardware/drm_gralloc/gralloc_drm_nouveau.c and discovered by the time it was wrote, libdrm was a bit different than now. Some differences I observed:

- Many libdrm include files do not exist anymore:
=> nouveau_drmif.h: This had some functions to handle devices (nouveau_device_open_existing, nouveau_device_open, nouveau_device_close, nouveau_device_get_param and nouveau_device_set_param). 

Checked these functions were moved to external/drm/nouveau/private.h and external/drm/nouveau/nouveau.h. 

I couldn't find a function named nouveau_device_close on new implementation. I assumed it was renamed to nouveau_device_del, as this function doesn't exist in old implementation

 => nouveau_channel.h: This handle channels (not sure what channels represent dma channels or some other resource used by gpus). It implemented 2 functions: nouveau_channel_alloc and nouveau_channel_free

These functions are not declared in newer implementations of libdrm. Suppose they are treated by a more generic function (nouveau_object_new?).

Currently, nouveau drm gralloc failure on creating a channel is not treated as fatal...

 => nouveau_bo.h: This handle buffers (the gpu memory allocated itself). Lots of functions are declared:
"nouveau_bo_new, nouveau_bo_new_tile, nouveau_bo_user, nouveau_bo_wrap, nouveau_bo_handle_get, nouveau_bo_handle_ref, nouveau_bo_ref,
      nouveau_bo_map_range, nouveau_bo_map_flush, nouveau_bo_map, nouveau_bo_unmap, nouveau_bo_busy and nouveau_bo_pending"

Assumed nouveau_bo_handle_get and  nouveau_bo_handle_ref were renamed to nouveau_bo_name_get and  nouveau_bo_name_ref, respectively

nouveau_bo_new_tile was removed. I interpreted that it was merged with nouveau_bo_new (in old code, the last one called the first, passing 0 to tiling parameters).
Now receives a parameter called nouveau_bo_config (a union of structs) in place of tiling info:

nouveau_bo_unmap is another function apparently replaced by a more generic one (nouveau_bo_ref)

Some constants are not declared in new libdrm (NOUVEAU_BO_TILE_32BPP, NOUVEAU_BO_TILE_16BPP and NOUVEAU_BO_TILE_SCANOUT, for example). They are used for mask.

PART 2: Changing the code.

Based on the assumptions above, I changed hardware/drm_gralloc/gralloc_drm_nouveau.c to fit on new libdrm implementation. I attached the modified file.

Also, mesa changes were made (based on 10.1.x). Attached the procedure to the file (comments are in Portuguese - I can translate if someone wishes...)

PART 3: Creating the ISO

I enabled nouveau in device/generic/x86/BoardConfig.mk I created a ISO with these changes (uploading to my google drive - I'll post the link later ) 
I only had chance to test it with 2 Nvidia boards, with different results:
 - Nvidia GTX 550 TI: Enters in graphic mode, but keep displaying "ANDROID" logo and don't advance.
 - Nvidia 8600: Enters graphic mode, but display seems "out of sync"


ENDING

Hope these info can be usefull someday to include Nvdidia support to Android-x86.

Also, many you guys in this mail group are very skilled. I believe you can do the necessary changes to include support
gralloc_drm_nouveau.c
alteracoes_compilacao_mesa_nouveau.txt

pstglia

unread,
Jun 6, 2014, 8:16:34 PM6/6/14
to andro...@googlegroups.com
Here is the link the ISO generated with changes on drm gralloc nouveau. 


You can try it on Nvidia cards. If a miracle happens, maybe it works in your hardware. Otherwise, you can attach logcat/dmesg here. Will be helpfull

Regards,
pstglia

Mauro Rossi

unread,
Jun 7, 2014, 5:39:44 AM6/7/14
to andro...@googlegroups.com
Hi,

I've tested on a GT 610

When running as Live, ANDROID screen is not reached, looking messages in Live Debug there is a process starting and exiting every few seconds, it seams the same problem you mention.

When selecting Live VESA, ANDROID is correctly lauched and I can install apps see youtube videos,
but I don't get Mesa info in Settings => About Tablet,
"OpenGL Check" and "OpenGL Demo" seem to work, and there is HW acceleration because I can see 480 fps in the OpenGL Demo.

How can I help in collecting some log about the Live standard session with Debug, I only get Pid of process crashing, what file do you need info in that case?

[I can do a cat and write down the log on paper and then report back to you]

M.

pstglia

unread,
Jun 7, 2014, 3:42:48 PM6/7/14
to andro...@googlegroups.com
Hi Mauro, thanks for the feedback.

By now, it would be nice nice if you could get gralloc debug info using this cmd (booting "live debug"). Could you get this info for me please?

logcat | grep "GRALLOC-KMS"

Also, this cmd will show if nouveau is being loaded:

busybox lsmod

Thanks!

pstglia

unread,
Jun 7, 2014, 5:20:00 PM6/7/14
to andro...@googlegroups.com
Forgot to mention this output. This is also important (more than others):

logcat | grep "GRALLOC-NOUVEAU"

Mauro Rossi

unread,
Jun 7, 2014, 5:59:52 PM6/7/14
to andro...@googlegroups.com
Hi,
I used [TAB] to enter DEBUG=2 line in the normal LiveCD grub menu entry, in order to avoid nomodeset and vga lines of the other grub menu entries.
I'll be a little verbose explaining what I did, because I'm not so experienced with Android shells (sort of learning by doing), so you can check what I did...

To save the text logs I mounted a second USB flashdrive that appeared sometimes mounting /dev/sdc1 and sometimes as already mounted /mnt/media_rw/usb1 .

Here follows output of busybox lsmod, at the initial shell:

Module Size Used by Not tainted
nouveau 747268 0
mxm_wmi 1485 1 nouveau
wmi 7246 2 nouveau,mxm_wmi
ttm 48936 1 nouveau
drm_kms_helper 27029 1 nouveau
drm 200044 3 nouveau,ttm,drm_kms_helper
hwmon 1591 1 nouveau
atkbd 14336 0


Here follows output of busybox lsmod, after 1st exit:
[As a comment/question is vgastate = nvidiafb wanted/necessary here or not?]

Module Size Used by Not tainted
pppoe 6602 0
rt2800usb 15112 0
rt2x00usb 8881 1 rt2800usb
rt2800lib 55584 1 rt2800usb
rt2x00lib 34711 3 rt2800usb,rt2x00usb,rt2800lib
mac80211 334238 3 rt2x00usb,rt2800lib,rt2x00lib
cfg80211 342003 2 rt2x00lib,mac80211
pcspkr 1362 0
r8169 43603 0
nvidiafb 30254 0
vgastate 6654 1 nvidiafb
i2c_i801 9349 0
snd_hda_codec_analog 61692 1
snd_hda_intel 27267 0
snd_hda_codec 123204 2 snd_hda_codec_analog,snd_hda_intel
snd_hwdep 4181 1 snd_hda_codec
snd_pcm 61373 2 snd_hda_intel,snd_hda_codec
snd_page_alloc 6282 2 snd_hda_intel,snd_pcm
snd_timer 14185 1 snd_pcm
shpchp 19400 0
parport_pc 13982 0
parport 17613 1 parport_pc
nouveau 747268 1
mxm_wmi 1485 1 nouveau
wmi 7246 2 nouveau,mxm_wmi
ttm 48936 1 nouveau
drm_kms_helper 27029 1 nouveau
drm 200044 3 nouveau,ttm,drm_kms_helper
hwmon 1591 1 nouveau
atkbd 14336 0

Here happens that after ANDROID logo the screen goes to "black and white big horizontal stripes"

Switched to shell with [CTRL+ALT+F1], here follows busybox lsmod at this point:

Module Size Used by Not tainted
configfs 19548 0
vivi 11166 0
videobuf2_vmalloc 2572 1 vivi
videobuf2_memops 2134 1 videobuf2_vmalloc
videobuf2_core 23042 1 vivi
acpi_cpufreq 9696 0
mperf 1035 1 acpi_cpufreq
kvm_intel 114789 0
kvm 286957 1 kvm_intel
mac_hid 2685 0
pppoe 6602 0
rt2800usb 15112 0
rt2x00usb 8881 1 rt2800usb
rt2800lib 55584 1 rt2800usb
rt2x00lib 34711 3 rt2800usb,rt2x00usb,rt2800lib
mac80211 334238 3 rt2x00usb,rt2800lib,rt2x00lib
cfg80211 342003 2 rt2x00lib,mac80211
pcspkr 1362 0
r8169 43603 0
nvidiafb 30254 0
vgastate 6654 1 nvidiafb
i2c_i801 9349 0
snd_hda_codec_analog 61692 1
snd_hda_intel 27267 0
snd_hda_codec 123204 2 snd_hda_codec_analog,snd_hda_intel
snd_hwdep 4181 1 snd_hda_codec
snd_pcm 61373 2 snd_hda_intel,snd_hda_codec
snd_page_alloc 6282 2 snd_hda_intel,snd_pcm
snd_timer 14185 1 snd_pcm
shpchp 19400 0
parport_pc 13982 0
parport 17613 1 parport_pc
nouveau 747268 6
mxm_wmi 1485 1 nouveau
wmi 7246 2 nouveau,mxm_wmi
ttm 48936 1 nouveau
drm_kms_helper 27029 1 nouveau
drm 200044 8 nouveau,ttm,drm_kms_helper
hwmon 1591 1 nouveau
atkbd 14336 0

...and I'll end the post with the only GRALLOC line found in logcat at this point, I had to write down on paper because the command logcat | grep |"GRALLOC" is endless, here it is:

E/GRALLOC-NOUVEAU( 2388):DEBUG PST - nouveau device created

No sign of GRALLOC-KMS in the logcat output.
Cheers

M.


Mauro Rossi

unread,
Jun 7, 2014, 6:09:03 PM6/7/14
to andro...@googlegroups.com
Ops, I forgot to mention that the posted logs are related to this configuration: ASUS P5B + Core2 Duo + Nvidia 9600GT, because I moved to a different machine.

I'll post logs from GT 610 and GTX 560 in the next days

M.

Mauro Rossi

unread,
Jun 8, 2014, 8:32:32 AM6/8/14
to andro...@googlegroups.com
Hi,

here follow the log files on the GT610 and the result are completely different from the previous on 9600GT, where there was no process crashing, but no display.
I hope the logs can be distinguished from reply content

On the Nvidia GT610 the first two busybox lsmod logs are similar to the ones on 9600GT, but ANDROID logo is not reached there is an error repeating every 5 seconds:

[timestamp] init: untracked pid  XXXX exited


NOTE: from now on XXXX is the pid of the process that crashed

The output of 'logcat | grep GRALLOC' is the following:

E/GRALLOC-NOUVEAU (XXXX): DEBUG PST - nouveau device created
E/GRALLOC-NOUVEAU (XXXX): unknown nouveau chipset 0xd9
E/GRALLOC-NOUVEAU (XXXX): DEBUG PST - nouveau_init failed
E/GRALLOC-DRM (XXXX): unsupported driver nouveau


The output of 'logcat | grep GL' is the following:

D/libEGL   (XXXX):            loaded system/lib/egl/libGLES_mesa.so
W/EGL-GALLIUM (XXXX): failed to create DRM screen
W/EGL-GALLIUM (XXXX): will fallback to other EGL driver if any
I/EGL-GALLIUM (XXXX):    using SW drivers


The essential output of 'logcat | grep DEBUG' is the following:

...
I/DEBUG    (XXXX): pid: XXXX, tid: XXXX name: surfaceflinger >>> /system/bin/surfaceflinger <<<
...
I/DEBUG    (XXXX): signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
...
I/DEBUG    (XXXX): backtrace:
I/DEBUG    (XXXX):     #00 0003be16   /sistem/bi/libc.so (tgkill+22)
I/DEBUG    (XXXX):     #01 00000005   <unknown>


Now looking at the SurfaceFlinger process whole pid  log :

I/SurfaceFlinger (XXXX): SurfaceFlinger is starting
I/SurfaceFlinger (XXXX): SurfaceFlinger's main thread ready to run. Initializing graphics H/W
D/libEGL   (XXXX):            loaded system/lib/egl/libGLES_mesa.so
E/GRALLOC-NOUVEAU (XXXX): DEBUG PST - nouveau device created
E/GRALLOC-NOUVEAU (XXXX): unknown nouveau chipset 0xd9
E/GRALLOC-NOUVEAU (XXXX): DEBUG PST - nouveau_init failed
E/GRALLOC-DRM (XXXX): unsupported driver nouveau
W/EGL-GALLIUM (XXXX): failed to create DRM screen
W/EGL-GALLIUM (XXXX): will fallback to other EGL driver if any
I/EGL-GALLIUM (XXXX):    using SW drivers
E/GRALLOC-NOUVEAU (XXXX): DEBUG PST - nouveau device created
E/GRALLOC-NOUVEAU (XXXX): unknown nouveau chipset 0xd9
E/GRALLOC-NOUVEAU (XXXX): DEBUG PST - nouveau_init failed
E/GRALLOC-DRM (XXXX): unsupported driver nouveau
E/SurfaceFlinger (XXXX): hwcomposer module not found
E/SurfaceFlinger (XXXX): ERROR: failed to open framebuffer (Invalid argument), aborting
F/libc     (XXXX): Fatal signal 6 (SIGABRT) at 0x0000....... (code =-6), thread XXXX (surfaceflinger)
I/DEBUG    (XXXX): pid: XXXX, tid: XXXX name: surfaceflinger >>> /system/bin/surfaceflinger <<<

These logs could mean that even if nouveau kernel module was loaded and mesa GLES library too, GRALLOC-NOUVEAU (or the nouveau version you used) did not recognize the GT610 chipset, GRALLOC-DRM could not use DRM, GALLIUM reverted to SW rendering, GRALLOC-NOUVEAU was noy happy with SW EGL rendering either and finally surfaceflinger crashed.

I still saw no sign of GRALLOC-KMS in the logcat output, at which point should I see that?

Anyway as final comment to this post, pstiglia I kinda have the feeling that you are inches away from the solution and the 50% of PC users having nvidia videocards will enjoy a lot all your findings.

M.






pstglia

unread,
Jun 8, 2014, 10:34:17 AM6/8/14
to andro...@googlegroups.com
Thank you very much again!

This message in particular is very interesting:
   E/GRALLOC-NOUVEAU (XXXX): unknown nouveau chipset 0xd9

There's a part on nouveau gralloc code where it tries to determine the family (NV40, Tesla, Fermi, etc) based on the chipset. It's a switch/case flow. Check it out:

...
        case 0xa0:
                info->arch = 0x50;
                break;
        case 0xc0:
                info->arch = 0xc0;
                break;
        default:
                ALOGE("unknown nouveau chipset 0x%x", info->dev->chipset);
                err = -EINVAL;
                break;
        }

Yours card chipset (GT610 - 0xd9) is not here, forcing the error message you see in log. Also, it avoids allocating buffer and creating a surface.
To solve it, I'll include 0xd9 to match 0xc0 arch (according to http://nouveau.freedesktop.org/wiki/CodeNames/, this is the family your gpu belongs to)

I'm also doing some other changes (Based on xf86 video nouveau, link http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/tree/src?h=master). This is the code the original author of drm-gralloc based on. If everything goes as expected, I'll post a new iso in a few hours.
One thing I'm changing is tile_mode value associated to arch 0x50 ( your 9600 GT belongs to this family for instance). Values atributed today are different from xf86 video (4,3,2,1,0 - xf86 uses 64, 48, 32, 16, 8 and 0).
0xc0 values are the same on xf86 and gralloc. 
I suspect these different values are the reason for the "big white stripes" you reported.

I'm also changing gpu channel alloc code (dma). I had disabled it because I was not sure how to code it (the function it used nouveau_channel_alloc, doesn't exist in the current implementation of libdrm). But now based on xf86 code, I think I have the answer 

Thank you very much again for your help!! 
I don't know if we can make it, but at least  we are trying :)

Mauro Rossi

unread,
Jun 8, 2014, 11:01:08 AM6/8/14
to andro...@googlegroups.com
I've tested on Nvidia 7600 GS

Boot is completed but then the GUI resets after 5 seconds for a while, then it stays stucked (cannot go back from console typing CTRL+ALT+F7.

Here follows logcat portion for Nvidia 7600 GS :

D/SurfaceFlinger (1281): Screen acquired type=0 flinger=0x415fa820
D/GRALLOC-DRM (1281): set master
E/GRALLOC-KMS (1281): failed to set crtc (Permission denied) (crtc_id 9, fb_id 55, conn 11, mode 1440x900)
D/EGL-GALLIUM (1279): cache full: buf 0x40fc6898, width 1440, height 900, format 5, usage 0x1a00
E/SurfaceFlinger (1281): error posting framebuffer. -13
D/SurfaceFlinger (1281): Screen released

then I see a repetion with minor difference:

D/SurfaceFlinger (1281): Screen acquired type=0 flinger=0x415xxxxx
[this is the ony new line] =>   D/SurfaceFlinger (1281): screen was previously acquired
D/GRALLOC-DRM (1281): set master
E/GRALLOC-KMS (1281): failed to set crtc (Permission denied) (crtc_id 9, fb_id 55, conn 11, mode 1440x900)
D/EGL-GALLIUM (1279): cache full: buf 0x40xxxxxxx, width 1440, height 900, format 5, usage 0x1a00
E/SurfaceFlinger (1281): error posting framebuffer. -13
D/SurfaceFlinger (1281): Screen released

Looking into dmesg, we have:

WindowsManager (pid) segfault at c ip 78.......... sp 78............. in libdrm_nouvearu.so

Sorry for not attaching the logs, but I'm not able to mount usb flash drive on these other PCs when Live booting, I had to handwrite the logs.

M.


Mauro Rossi

unread,
Jun 8, 2014, 8:54:01 PM6/8/14
to andro...@googlegroups.com
Hi,

looking at the compact switch construct found  in http://cgit.freedesktop.org/~olv/drm_gralloc/tree/gralloc_drm_nouveau.c ,

adding a case for 0xd0 would add GF117 and GF119 support, while adding two cases for 0xe0 and 0xf0 would help supporting Kepler family (which should be supported starting from kernel 3.4).


Here follows the complete switch construct. If could provide me an iso I will test on various cards (I have also GeForce 7025,  6200, 8500GT, GT210, GTX 560)
Will all the necessary firmwares be already included in the iso?

M.

	switch (info->dev->chipset & 0xf0) {
	case 0x00:
		info->arch = 0x04;
		break;
	case 0x10:
		info->arch = 0x10;
		break;
	case 0x20:
		info->arch = 0x20;
		break;
	case 0x30:
		info->arch = 0x30;
		break;
	case 0x40:
	case 0x60:
		info->arch = 0x40;
		break;
	case 0x50:
	case 0x80:
	case 0x90:
	case 0xa0:
		info->arch = 0x50;
		break;
	case 0xc0:
        case 0xd0:

info->arch = 0xc0; break;
	case 0xe0:
        case 0xf0:
info->arch = 0xe0; break;
default: LOGE("unknown nouveau chipset 0x%x", info->dev->chipset); err = -EINVAL; break;

Message has been deleted

Mauro Rossi

unread,
Jun 8, 2014, 9:01:33 PM6/8/14
to andro...@googlegroups.com
Sorry, in the code I just posted, default: invokes LOGE,
in your code default: invokes ALOGE

It's probably better to invoke ALOGE, to avoid a bug, as it was in your example.

M.

pstglia

unread,
Jun 8, 2014, 11:03:24 PM6/8/14
to andro...@googlegroups.com
Hi Mauro,

I created this new iso:

1) I included the kepler chips you posted. Also, included 0xd9 chip (your GT610 returned this chip id). 
2) Other changed was tile_mode values associated for 0x50 family (Tesla) as I commented last message. Changed the value of tile_flags.
3) Dma channel alloc requires more research, so I gave it up by now...
4) Included some more debug messages
I attached the modified source (gralloc_drm_nouveau.c)


About the firmwares: I'm creating the iso with the regular kernel provided by Android-x86 RC2 (3.10.40). No extra firmwares.
However, as far as I know, they are only required for video decoding/encoding (which Android-x86 currently doesn't support)

One more thing: Here's a way to save logcat/dmesg booting from flashdrive:
You must plug a second flash drive with a fat32/ext2 or ext3 partition. Then do the following:

cd /data
mkdir x

# Note: sdc1 was the device/partition associated in my system. Yours may be different. dmesg shows you the device created
busybox mount /dev/block/sdc1 x


cd x
logcat > logcat_output_DEVINFO_YYYYMMDD.txt 
# Wait about 10 seconds to collect enough info. Then press CTRL+C to stop writing

dmesg > dmesg_output_DEVINFO_YYYYMMDD.txt

cd ..
busybox umount x
# after unmounting, you can unplug the flashdrive



Thanks and have a nice week.
pstglia
gralloc_drm_nouveau.c

Mauro Rossi

unread,
Jun 9, 2014, 9:10:55 AM6/9/14
to andro...@googlegroups.com
Hi, in order to support GT610 the case valute should be

case 0xd0:

This is due to the fact that switch argument is 'chipset & 0xf0' and for chipset being 0xd9, the evaluated argument will be 0xd0.

Anyway there's no rush, because I'll be able to test again on GT610 only in the weekend, at my parents house, in the meantime I can use your last ISO, on several other Nvidia cards I have at my house. Thanks a lot!

I would be also interested in testing on older cards, which is the minimum hw that could work?

I'd also like that nouveau was able to support GeForce2mx, GeForce FX5200, not only for Android-x86 but especially for Ubuntu on PPC, but that is another story...

Mauro

Mauro Rossi

unread,
Jun 9, 2014, 1:37:09 PM6/9/14
to andro...@googlegroups.com
I looked into the attached gralloc_drm_nouveau.c and case 0xd0 is already present, so no need to rebuild ISO for now.
Thanks

Mauro
Message has been deleted

pstglia

unread,
Jun 9, 2014, 9:57:40 PM6/9/14
to andro...@googlegroups.com
Hi Mauro
 
>> This is due to the fact that switch argument is 'chipset & 0xf0' and for chipset being 0xd9, the evaluated argument will be 0xd0.

Thanks for the tip. Hadn't noticed that.
 
>> I'd also like that nouveau was able to support  GeForce2mx, GeForce FX5200, not only for Android-x86 but especially for Ubuntu on PPC, but that is another story...

Maybe it's not possible to support Android-x86 on these cards, due the lack of OpenGL ES 2.0 / EGL support

Mauro Rossi

unread,
Jun 10, 2014, 7:25:46 PM6/10/14
to andro...@googlegroups.com
Hi,
Here are dmesg log and logcat for GTX 560 (NVCE aka GF114) which stays stuck at ANDROID logo.

Mauro


dmesg_output_GTX560_20140610.txt
logcat_output_GTX560_20140610.txt

pstglia

unread,
Jun 10, 2014, 9:52:06 PM6/10/14
to andro...@googlegroups.com
Hi Mauro, 

Seems binder is crashing during memory allocation:
vmap allocation for size 1044480 failed: use vmalloc=<size> to increase size

Could you include this kernel parameter and test it again please?

vmalloc=256M

Thanks

Mauro Rossi

unread,
Jun 11, 2014, 5:16:58 PM6/11/14
to andro...@googlegroups.com
Hi,
adding the vmalloc = 256M kernel parameter I get result similar to the one seen on Nvidia 7600 GS,
after ANDROID logo I see the boot completed, with screen for language selection, but there's no mouse pointer and I cannot proceed with android setup,
after a 10-20 seconds the screen goes black and language screen reappears (some kind of reset) and after the GUI is not anymore available.

Anyway the display initially works for a while.
Log of dmesg
M.

dmesg_output_GTX560_20140611_vmalloc_256M.txt

Mauro Rossi

unread,
Jun 11, 2014, 5:21:38 PM6/11/14
to andro...@googlegroups.com
and logcat

logcat_output_GTX560_20140611_vmalloc_256M.txt

Mauro Rossi

unread,
Jun 11, 2014, 7:27:42 PM6/11/14
to andro...@googlegroups.com
And here logs taken from GeForce 7025 (which is reported by nouveau as NV4C GeForce 6150LE ???)
Same GUI resets after language selection screen.

Mauro

dmesg_output_GeForce7025_20140612.txt
logcat_output_GeForce7025_20140612.txt

pstglia

unread,
Jun 12, 2014, 7:11:25 AM6/12/14
to andro...@googlegroups.com
libdrm_nouveau segfault in both cases.
Maybe due incorrect or missing parameters on drm gralloc.
Investigating how can we trace it with a higher log level.

Any blessing soul to give us a hand nearby? :)

Chih-Wei Huang

unread,
Jun 12, 2014, 11:12:13 AM6/12/14
to Android-x86
Can't you use adb?

adb connect ip_of_the_device
adb logcat -v threadtime
...


--
Chih-Wei
Android-x86 project
http://www.android-x86.org

pstglia

unread,
Jun 12, 2014, 1:59:50 PM6/12/14
to andro...@googlegroups.com
Thanks for the hint Mr. Wei!

Mauro,
Can you provide these logs on your hardware please?

cd /path_to_your_mounted_flashdrive
adb connect localhost
adb logcat -v threadtime >> output_logcat_threadtime_DEVICE_YYYYMMDD.txt

Thanks.
ps (off-Topic): Today's World Cup 2014 opening :D

Mauro Rossi

unread,
Jun 12, 2014, 5:17:22 PM6/12/14
to andro...@googlegroups.com
Here is logcat with threadtime option for GTX560,

and for G210 I was able to get with method suggested by Chih-Wei, thanks a lot!

Mauro




output_logcat_threadtime_GTX560_20140612_vmalloc_256M.zip
output_logcat_threadtime_G210_20140612.zip

Mauro Rossi

unread,
Jun 12, 2014, 5:55:40 PM6/12/14
to andro...@googlegroups.com
...and here 8500GT and GeForce7025
output_logcat_threadtime_8500GT_20140612.zip
logcat_output_threadtime_GeForce7025_20140612.zip

pstglia

unread,
Jun 12, 2014, 11:52:11 PM6/12/14
to andro...@googlegroups.com
Hi,

Status for 0xC0:

As I could check, due the lack of a DMA channel, it's using "DRM_SWAP_SETCRTC" as swap_mode (A method to send data to GPU).  If a channel existed, it would use DRM_SWAP_FLIP (by the way, the only method supported on gralloc_drm_radeon)

However, it's not allowing to use this method:

E/GRALLOC-KMS( 1379): failed to set crtc (Permission denied) (crtc_id 13, fb_id 43, conn 15, mode 1280x1024)

Have to research what is needed to allow this operation (I believe a incorrect parameter can also cause this).
Another option is including channel alloc and it will use DRM_SWAP_FLIP (have to figure out how to deal with push and pull buffers and integrate them to gralloc)

Status for 0x50:

Failure on while trying to allocate a buffer object:
E GRALLOC-NOUVEAU: failed to allocate bo (flags 0x80000001, size 0, tile_mode 0x40, tile_flags 0x70)

I saw some differences on calculating align. I've changed part of the code I think where the problem is (returning correct tile height - copied a macro named NV50_TILE_HEIGHT from xf86-video-nouveau).
Have not generated another ISO yet because I'm giving focus on 0xC0 by now. Also, I think even if this problem is solved, we'll have the permission denied on CRTC in this case also. But I can be wrong


Let's keep trying. Help of any kind is very welcome 

Mauro Rossi

unread,
Jun 13, 2014, 1:15:20 PM6/13/14
to andro...@googlegroups.com
Looking in logs I've also found a segfault:

segfault error in libdrm_nouveau.so

I am available and happy to collect logs to help.
Mauro

pstglia

unread,
Jun 13, 2014, 10:49:15 PM6/13/14
to andro...@googlegroups.com
Thanks again for the support. I'll try to find a way to make crtc work.

Ps: As I posted before, can post a iso with some changes for 0x50. However, It's very probably it also requires crtc.
Do you want me to upload it?

pstglia

unread,
Jun 14, 2014, 3:59:05 PM6/14/14
to andro...@googlegroups.com
Hi Mauro,

When possible can you get 2 dmesg outputs on one of yours 0xc0 hardwares?

1) Output with "drm.debug=4" kernel parameter (to log DRM_DEBUG_KMS debug messages)
2) Output with "drm.debug=7" kernel parameter (will produce a lot of debugging messages, including CORE, DRIVER and KMS)

Although "7" value includes "4" info ( bitmask 111), I want to have a "cleaner" log first.

I'm trying to discover why DRM_IOCTL_MODE_SETCRTC ioctl call (the call made by drm_kms_set_crtc => drmModeSetCrtc ) is returning failure (Permission denied). 
With this info we can confirm if gralloc_drm_set_master (drmSetMaster - a pre-requisite to set CRTC mode) is returning correctly.

Mauro Rossi

unread,
Jun 14, 2014, 5:28:47 PM6/14/14
to andro...@googlegroups.com
As you wish, no problem, it doesn't takes not much effort to take logs.

I found some hint in this forum and others about "failed to set crtc" and there were suggestions to use a fail safe resolution and bits per pixel value, using following shell commands:

setprop debug.drm.mode=800x600@32
killall surfaceflinger
 
The GUI restarts at the new resolution, but there are still "failed to set crtc" errrors and it still crashes with sometimes with segfault in libdrm_nouveau.so and other times in  libGLES_mesa.so
I've tried with various resolutions and bpp, but still no luck

I was able to reach WiFi configuration, only once, but after that there was a crash at configuration of Google Account with segfault in libGLES_mesa.so

<6>[  452.935092] ndroid.systemui[10597]: segfault at 8 ip 7787dc6b sp bfdb3400 error 4 in libGLES_mesa.so[77822000+702000]
<6>[  453.137392] binder: release 10597:10722 transaction 131660 out, still active
<6>[  453.379911] oid.setupwizard[10731]: segfault at 8 ip 7787dc6b sp bfdb3400 error 4 in libGLES_mesa.so[77822000+702000]

Here are various logs, in the file name there is indication of drm.debug.mode changes.

Mauro
Archive.zip

pstglia

unread,
Jun 14, 2014, 6:37:09 PM6/14/14
to andro...@googlegroups.com
I was expecting messages like this with drm.debug=7 (this is what I get with my hardware, radeon):

<7>[   79.097455] [drm:drm_crtc_helper_set_config], [CRTC:10] [FB:56] #connectors=1 (x y) (0 0)
<7>[   79.097469] [drm:drm_crtc_helper_set_config], [CONNECTOR:18:VGA-1] to [CRTC:10]
<7>[   79.097472] [drm:drm_framebuffer_unreference], FB ID: 56
<7>[   79.097474] [drm:drm_framebuffer_reference], FB ID: 56
...
<7>[   79.097478] [drm:drm_crtc_helper_set_config], [CRTC:11] [NOFB]
<7>[   79.097483] [drm:radeon_atom_encoder_dpms], encoder dpms 33 to mode 3, devices 00000008, active_devices 00000000
<7>[   79.097673] [drm:dce5_crtc_load_lut], 0
<7>[   79.097701] [drm:dce5_crtc_load_lut], 0
<7>[   79.107048] [drm:dce5_crtc_load_lut], 0

I checked the dmesg logs and none of them have this info.

Could you check if this was really included on grub before booting?
Just in case, include also DEBUG=2

===

debug.drm.mode will be usefull. Thanks for this
By now, let's just check out drm.debug output

Thanks!

Mauro Rossi

unread,
Jun 14, 2014, 7:15:18 PM6/14/14
to andro...@googlegroups.com
You're welcome
My previous post was related to logs that were collected before your post.

Here are the ones with DEBUG=2 (Live Debug) and drm.debug = 4 or 7

The problem with drm.debug=7 is that is not possible to get the first 50 seconds without automatic scripts launched by boot sequence

Is somehow possible enlarge the kernel dmesg ring buffer to at least some megabytes?

Mauro
NVC0_drm_debug.zip

Mauro Rossi

unread,
Jun 14, 2014, 7:24:02 PM6/14/14
to andro...@googlegroups.com
Hi,

Can I ask you confirmation about the possible interference of nvidiafb kernel driver?
Thx

M.

  1. Are you clear of other kernel drivers that break Nouveau?
    • Some kernel drivers make Nouveau misbehave and must not be used, e.g.: nvidia.ko (the proprietary driver), rivafb, nvidiafb - more information can be found in KernelModeSetting. Look in your kernel log and lsmod output for any sign of these and disable them. If you cannot find a kernel module anywhere, but it still magically loads, maybe it is in your initramfs.

pstglia

unread,
Jun 14, 2014, 9:14:32 PM6/14/14
to andro...@googlegroups.com
Very Interesting info. Nice job!

It's being load by detection script. According to lsmod output you provided earlier, it's not supposed to be used:

nvidiafb               30254  0


But, the troubleshooting you posted is clear.It may cause problems

You can do the following test to confirm if this is the problem:

1) Boot under debug mode (DEBUG=2)
2) Before the 2nd exit (when showed "Use Alt-F1/F2/F3 to switch between virtual consoles"), unload these modules with:
modprobe -r nvidiafb
modprobe -r vgastate

3) Confirm if the modules were unloaded :

lsmod

4) If unloaded, confirm also if nouveaufb is shown under /proc/fb

cat /proc/fb

5) Type exit and continue booting.




And thanks for the debug info. According to this (https://wiki.archlinux.org/index.php/Boot_debugging) you can increase log buffer with log_buf_len=SIZE (ex: log_buf_len=10M). But the info you provided is enough for now
Hope unloading nvidiafb give us positive results! :)

Regards,
pstglia
Message has been deleted
Message has been deleted

pstglia

unread,
Jun 15, 2014, 12:47:47 PM6/15/14
to andro...@googlegroups.com
Hi Mauro,

- Wrong resolution may cause this failure (in fact any other wrong parameter).
  But I also suspect the failure on DRM_IOCTL_SET_MASTER logs with drm.debug shows. If not master, crtc cannot be set.

 - Don't know how to increase log ring buffer. I thought log_buf_len would be enough. Have to google it to discover how to increase.

I have a new iso with some changes and extra debug info:

Changes:

1) DRM_IOCTL_SET_MASTER/DRM_IOCTL_DROP_MASTER call is returning -22 error code (EINVAL)

  This function is required for setting crtc mode. One of the reasons for failure is a non-root calling this:
  DRM_IOCTL_DEF(DRM_IOCTL_SET_MASTER, drm_setmaster_ioctl, DRM_ROOT_ONLY)

  To confirm if this is a permission matter, I changed it under kernel/drivers/gpu/drm/drm_drv.c
    DRM_IOCTL_DEF(DRM_IOCTL_SET_MASTER, drm_setmaster_ioctl, 0)

  The same for dropmaster:
   DRM_IOCTL_DEF(DRM_IOCTL_DROP_MASTER, drm_dropmaster_ioctl, 0)

2)  Removed nvidiafb from kernel config. This way it will not be loaded

3) Included function NV50_TILE_HEIGHT on gralloc_drm_nouveau.c (copied from xf86 video nouveau). Using it to calculate align for 0x50 (changed in hardware/drm_gralloc/gralloc_drm_nouveau.c)

4) Included test on gralloc_drm_set_master to check if drmSetMaster returned no error (hardware/drm_gralloc/gralloc_drm.c). In case of failure, it will print on dmesg:
  Could not set drm master - returned_errormsg

If you are going to test it, do it without drm.debug first.

Regards,
pstglia







Em domingo, 15 de junho de 2014 11h39min27s UTC-3, Mauro Rossi escreveu:
Somehow I see the same problem of GUI restarting described here: https://groups.google.com/forum/#!msg/android-x86/zILa6fmQ1Ec/qmQSWrphDRIJ

but in our case with GT610 (NVD9) the resolution seem to be correct 1680x1050

What is also strange, I never saw GRALLOC-KMS advertise the supported modes and GRALLOC-MOD line for selection of the mode,
but I'm not certain if didn't saw them because of logcat ring buffer rewrite.

Mauro

gralloc_drm.c
gralloc_drm_nouveau.c

Mauro Rossi

unread,
Jun 15, 2014, 1:23:10 PM6/15/14
to andro...@googlegroups.com
Hi,
I have deleted previous posts, because I messed with kernel parameters and the conflicting kernel drivers were still loading,
then I followed line by line your instructions and I have removed several modules using modprobe -r :

nvidiafb
vgastate
vesafb

and...the cursed one:

vivi

when I did that I got the following output:

vivi-000: unregistering video0

at relative timestamp 300s I restarted the GUI with following command:

killall surffaceflinger


and Ta-Da!
I have a stable GUI and I can navigate with [TAB], [ENTER]  the screens, apps menu.
Question: Do you know why mouse cursor is not showing?

Entering in Settings or launching apps causes the GUI to crash, but after a few seconds it is again stable, it is a huge improvement!!!

Do you know if I can blacklist modules? [I tried with module.blacklist=true, with blacklist=module1,module2,module3, yet to try with rdblacklist and module.blacklist=yes syntaxes]

I already have new log but I will collect new one with your new ISO.
Mauro



pstglia

unread,
Jun 15, 2014, 2:43:49 PM6/15/14
to andro...@googlegroups.com
Good! You are on the right way!

quoting source code comments about vivi (kernel/drivers/media/platform/vivi.c):
"Virtual Video driver - This code emulates a real video device with v4l2 api"

By now, I have no idea why mouse is not working. With a log info, I can try to figure out. 

About blacklist: There's a file under /system/etc called "modules.blacklist". You can include the module you don't want to load. Ex:
blacklist evbug
blacklist btusb
blacklist bluetooth

Ps: Have you tried downloading Android sources and build a compile environment? This will help you to customize a debug iso

Regards,
pstglia

Mauro Rossi

unread,
Jun 15, 2014, 4:12:55 PM6/15/14
to andro...@googlegroups.com
Hi,

The procedure to get a stable GUI is:

1) At ANDROID logo, to press ALT+F1 and remove vivi module with command 

busybox modprobe -r vivi

2) to restart the GUI (even if not much ortodox)

killall surfaceflinger

3) avoid inserting Google Account, at all cost, or system will begin an infine loop
That's it.

Would it be possible for you to build an ISO having vivi module removed from kernel config, in order that it should be possible to boot straight to stable GUI?
Thanks a lot

Unfortunately I don't have a stable and fast build environment always at my disposal, but I'll try to setup one soon.
I would like to play with definition of a new target with latest stable mesa.

Mauro
GUI_working.zip

pstglia

unread,
Jun 15, 2014, 5:49:34 PM6/15/14
to andro...@googlegroups.com
Mauro,

Here's the iso without vivi:



I just commented "init_hal_camera" on /system/etc/init.sh. This is where vivi is loaded:

# This is the function. If there's a /dev/video0, it is loaded
function init_hal_camera()
{
        [ -c /dev/video0 ] || modprobe vivi
}

# Here where I commented
function do_init()
{
        init_misc
        init_hal_audio
        init_hal_bluetooth
        #init_hal_camera
        init_hal_gps
        init_hal_gralloc
        init_hal_hwcomposer
        init_hal_lights
        init_hal_power
        init_hal_sensors
        init_tscal
        init_ril
        chmod 640 /x86.prop
        post_init
}


About the mouse issue: Are you using a USB mouse or using o touchpad? Log shows as you had connected a usb mouse, right?

Mauro Rossi

unread,
Jun 15, 2014, 6:26:02 PM6/15/14
to andro...@googlegroups.com
Hi, 

I was reading again your first post and I have (luckily) found a webpage where is possible to check at lot of your assumptions, if not all of them, about the new vs old functions and arguments.
It may also help with dma channels :-)

I basically googled the new and old function names toghether, supposing that someone else had the same problem before...

'drm nouveau nouveau_device_close nouveau_device_del' (without quotes)

and I found this (very rich and with + / - diff very easy to read):


this other for crosscheck, about "port to new libdrm nouveau" (yeesss!):


and this website has also info, but structured in a different way:



The tricky thing is that some functions have inverted arguments and some others significant changes in the arguments.

I hope they will be useful.

Mauro

Mauro Rossi

unread,
Jun 15, 2014, 6:35:10 PM6/15/14
to andro...@googlegroups.com
Thanks, already downloading even if here in Italy is past midnight.
 
About the mouse issue: Are you using a USB mouse or using o touchpad? Log shows as you had connected a usb mouse, right?

Yes, usb mouse is connected, but there is no black pointer on the screen (I was never able to see and control the pointer on all NV50 and NVC0 cards I tested),
probably due to some lack in drm porting, but we will address that soon...I am confident.

Mauro

pstglia

unread,
Jun 15, 2014, 9:19:52 PM6/15/14
to andro...@googlegroups.com
Thanks, already downloading even if here in Italy is past midnight.
You should be sleeping :)
In Brazil is GMT - 3 ( now it's 10:19 pm here).

I also created another ISO using mesa 9.2.0 (required some changes to compile).
In case you want to test,  here's the ISO link:

And here the git patches (mesa 9.2.0 + drm_gralloc - in case anyone else wants to compile it)

I'll send the git patches for 10.1.x later (I had already sent a procedure in the earlier posts)

Regards,
pstglia

pstglia

unread,
Jun 15, 2014, 10:51:14 PM6/15/14