Re: [Nouveau] Problems getting nouveau to work with either Geforce GT710 or Geforce 9800GT on ARM Cortex-A9

[Luís Mendes]

Hi Rob, Ilia,

Thanks for your information.

I'll try to have a look into the nouveau code... maybe I can find why
the dma fence doesn't complete. In the amdgpu and radeon drivers I am
being able to get further with the ARM platform, may be I can compare
how they're handling the dma transfers, despite I am getting gpu
lockups after a while of playing videos on ARM with AMD cards too, but
at least it is going a lot further.

Can you point me the files or functions in the nouveau code, where the
initialization tests dma transfers are started? I can try to find
them, but this could save me some time.

Thanks,
Luís

On Thu, Jan 25, 2018 at 2:47 PM, Rob Clark  wrote:
> On Thu, Jan 25, 2018 at 8:57 AM, Ilia Mirkin  wrote:
>> On Thu, Jan 25, 2018 at 8:47 AM, Luís Mendes  wrote:
>>> Sorry for alI these individual emails, but I think is more readable
>>> this way, by having each independent information in a separate email.
>>>
>>> I also have these additional cards that I can try: Gefoce GT 1030 and
>>> Geforce GTX 1050 Ti.
>>>
>>> I have tried Geforce GT 1030 and it is working nicely but without
>>> hardware acceleration. Without the hardware acceleration I am able to
>>> get into X (Ubuntu Mate 17.10) and run glmark2.
>>> dmesg follows in attachment.
>>
>> This is a GP108 for which you need not-yet-upstream code to get acceleration.
>>
>>>
>>> I believe this indicates there is no issue with cards initialization,
>>> but is rather something to do with the hardware acceleration code.
>>
>> Someone associated with (or working at?) RH was investigating this for
>> some server-type ARM board with PCIe slots. (Was it you? Rob Clark,
>> CC'd, will remember who it was, and may be able to point you in an
>> appropriate direction.) I think that there were various odd issues
>> with coherency which remained only lightly diagnosed. Note that all
>> your boots instantaneously print "GPU lockup, have a nice day".
>> Everything after that is largely irrelevant.
>
> well, I don't actually have any ARM board w/ PCIe yet.. although I
> would expect that drm_cflush* being no-ops on arm/arm64 isn't likely
> to help things.
>
> BR,
> -R
>
>> This happens when it tries to execute some very basic things and sees
>> that there is no progress. This means sticking a command buffer on the
>> DMA ring, letting the GPU execute it, and making sure that the fence
>> is hit as seen by the CPU. I would recommend tracking down why the
>> accel doesn't work (i.e. you get that message), and not worry about
>> little details like "image appears on screen".
>>
>> Unfortunately the initialization logic in nouveau is a giant pile of
>> spaghetti (with various arguably good reasons, but it doesn't change
>> the end result), so tracking down exactly what fails in the GPU init
>> will be a bit of an undertaking. You should join #nouveau on
>> irc.freenode.net and get some additional advice there.
>>
>> Good luck,
>>
>>   -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Problems getting nouveau to work with either Geforce GT710 or Geforce 9800GT on ARM Cortex-A9

[Rob Clark]

On Thu, Jan 25, 2018 at 8:57 AM, Ilia Mirkin  wrote:
> On Thu, Jan 25, 2018 at 8:47 AM, Luís Mendes  wrote:
>> Sorry for alI these individual emails, but I think is more readable
>> this way, by having each independent information in a separate email.
>>
>> I also have these additional cards that I can try: Gefoce GT 1030 and
>> Geforce GTX 1050 Ti.
>>
>> I have tried Geforce GT 1030 and it is working nicely but without
>> hardware acceleration. Without the hardware acceleration I am able to
>> get into X (Ubuntu Mate 17.10) and run glmark2.
>> dmesg follows in attachment.
>
> This is a GP108 for which you need not-yet-upstream code to get acceleration.
>
>>
>> I believe this indicates there is no issue with cards initialization,
>> but is rather something to do with the hardware acceleration code.
>
> Someone associated with (or working at?) RH was investigating this for
> some server-type ARM board with PCIe slots. (Was it you? Rob Clark,
> CC'd, will remember who it was, and may be able to point you in an
> appropriate direction.) I think that there were various odd issues
> with coherency which remained only lightly diagnosed. Note that all
> your boots instantaneously print "GPU lockup, have a nice day".
> Everything after that is largely irrelevant.

well, I don't actually have any ARM board w/ PCIe yet.. although I
would expect that drm_cflush* being no-ops on arm/arm64 isn't likely
to help things.

BR,
-R

> This happens when it tries to execute some very basic things and sees
> that there is no progress. This means sticking a command buffer on the
> DMA ring, letting the GPU execute it, and making sure that the fence
> is hit as seen by the CPU. I would recommend tracking down why the
> accel doesn't work (i.e. you get that message), and not worry about
> little details like "image appears on screen".
>
> Unfortunately the initialization logic in nouveau is a giant pile of
> spaghetti (with various arguably good reasons, but it doesn't change
> the end result), so tracking down exactly what fails in the GPU init
> will be a bit of an undertaking. You should join #nouveau on
> irc.freenode.net and get some additional advice there.
>
> Good luck,
>
>   -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Problems getting nouveau to work with either Geforce GT710 or Geforce 9800GT on ARM Cortex-A9

[Ilia Mirkin]

On Thu, Jan 25, 2018 at 8:47 AM, Luís Mendes  wrote:
> Sorry for alI these individual emails, but I think is more readable
> this way, by having each independent information in a separate email.
>
> I also have these additional cards that I can try: Gefoce GT 1030 and
> Geforce GTX 1050 Ti.
>
> I have tried Geforce GT 1030 and it is working nicely but without
> hardware acceleration. Without the hardware acceleration I am able to
> get into X (Ubuntu Mate 17.10) and run glmark2.
> dmesg follows in attachment.

This is a GP108 for which you need not-yet-upstream code to get acceleration.

>
> I believe this indicates there is no issue with cards initialization,
> but is rather something to do with the hardware acceleration code.

Someone associated with (or working at?) RH was investigating this for
some server-type ARM board with PCIe slots. (Was it you? Rob Clark,
CC'd, will remember who it was, and may be able to point you in an
appropriate direction.) I think that there were various odd issues
with coherency which remained only lightly diagnosed. Note that all
your boots instantaneously print "GPU lockup, have a nice day".
Everything after that is largely irrelevant.

This happens when it tries to execute some very basic things and sees
that there is no progress. This means sticking a command buffer on the
DMA ring, letting the GPU execute it, and making sure that the fence
is hit as seen by the CPU. I would recommend tracking down why the
accel doesn't work (i.e. you get that message), and not worry about
little details like "image appears on screen".

Unfortunately the initialization logic in nouveau is a giant pile of
spaghetti (with various arguably good reasons, but it doesn't change
the end result), so tracking down exactly what fails in the GPU init
will be a bit of an undertaking. You should join #nouveau on
irc.freenode.net and get some additional advice there.

Good luck,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Problems getting nouveau to work with either Geforce GT710 or Geforce 9800GT on ARM Cortex-A9

[Luís Mendes]

Sorry for alI these individual emails, but I think is more readable
this way, by having each independent information in a separate email.

I also have these additional cards that I can try: Gefoce GT 1030 and
Geforce GTX 1050 Ti.

I have tried Geforce GT 1030 and it is working nicely but without
hardware acceleration. Without the hardware acceleration I am able to
get into X (Ubuntu Mate 17.10) and run glmark2.
dmesg follows in attachment.

I believe this indicates there is no issue with cards initialization,
but is rather something to do with the hardware acceleration code.

Luís

On Thu, Jan 25, 2018 at 1:27 PM, Luís Mendes  wrote:
> The Geforce 9800GT also shows different behaviour without nvidiafb in
> the kernel. I get lengthy messages from nouveau, like the ones found
> in the email attachment.
> It also eventually gets into the lightdm login graphical screen, but
> with this card the screen is highly distorted, despite the mouse
> cursor being properly displayed and moving around properly.
>
> Luis
>
> On Thu, Jan 25, 2018 at 1:14 PM, Luís Mendes  wrote:
>> Hi Ben,
>>
>> Ok! I've removed nvidiafb from kernel config.
>>
>> Now linux is able to boot with the msi Geforce GT 710 card and
>> eventually ends up displaying a slightly distorted lightdm login
>> screen. The mouse cursor moves, but never changes to typing cursor
>> mode when hovering the password input box, and I am also unable to
>> enter the password, some graphics glitches in the login box too. There
>> are warnings about semaphores problems in the logs.
>> I believe one difference between this Cortex-A9 and Tegra SoCs is that
>> the Cortex-A9 has no IOMMU.
>>
>> In attachment follows the boot log and the dmesg kernel log.
>>
>> Luís
ubuntu@linux:~$ dmesg
[4.581738] ata3: SATA link down (SStatus 0 SControl 300)
[4.595035] usb usb5: We don't know the algorithms for LPM for this host, 
disabling LPM.
[4.603381] hub 5-0:1.0: USB hub found
[4.607153] hub 5-0:1.0: 1 port detected
[4.611310] usbcore: registered new interface driver usb-storage
[4.617437] mousedev: PS/2 mouse device common for all mice
[4.623515] armada38x-rtc f10a3800.rtc: rtc core: registered f10a3800.rtc as 
rtc0
[4.631161] i2c /dev entries driver
[4.634939] pca953x 0-0020: 0-0020 supply vcc not found, using dummy 
regulator
[4.651066] GPIO line 496 (pcie1.0-clkreq) hogged as input
[4.657605] GPIO line 499 (pcie1.0-w-disable) hogged as output/low
[4.664526] GPIO line 501 (usb3-current-limit) hogged as input
[4.671400] GPIO line 502 (usb3-power) hogged as output/high
[4.678107] GPIO line 507 (m.2 devslp) hogged as output/low
[4.684417] GPIO line 508 (sfp-los) hogged as input
[4.690022] GPIO line 509 (sfp-tx-fault) hogged as input
[4.696380] GPIO line 510 (sfp-tx-disable) hogged as output/low
[4.703036] GPIO line 511 (sfp-mod-def0) hogged as input
[4.709077] GPIO line 500 (pcie2.0-clkreq) hogged as input
[4.714593] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[4.715619] GPIO line 503 (pcie2.0-w-disable) hogged as output/low
[4.727055] pca953x 0-0020: interrupt support not compiled in
[4.732871] ata1.00: supports DRM functions and may not be fully accessible
[4.733201] IR NEC protocol handler initialized
[4.733203] IR RC5(x/sz) protocol handler initialized
[4.733204] IR RC6 protocol handler initialized
[4.733205] IR JVC protocol handler initialized
[4.733206] IR Sony protocol handler initialized
[4.733207] IR SANYO protocol handler initialized
[4.733208] IR Sharp protocol handler initialized
[4.733209] IR MCE Keyboard/mouse protocol handler initialized
[4.733210] IR XMP protocol handler initialized
[4.743415] (NULL device *): hwmon_device_register() is deprecated. Please 
convert the driver to use hwmon_device_register_with_info().
[4.743646] orion_wdt: Initial timeout 171 sec
[4.743915] sdhci: Secure Digital Host Controller Interface driver
[4.743916] sdhci: Copyright(c) Pierre Ossman
[4.744070] sdhci-pxav3 f10d8000.sdhci: Got CD GPIO
[4.801715] mmc0: SDHCI controller on f10d8000.sdhci [f10d8000.sdhci] using 
ADMA
[4.801818] sdhci-pltfm: SDHCI platform and OF driver helper
[4.802004] usbcore: registered new interface driver usbhid
[4.802005] usbhid: USB HID core driver
[4.802965] NET: Registered protocol family 10
[4.803970] Segment Routing with IPv6
[4.804003] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[4.804236] NET: Registered protocol family 17
[4.807621] 8021q: 802.1Q VLAN Support v1.8
[4.807695] ThumbEE CPU extension supported.
[4.807699] Registering SWP/SWPB emulation handler
[4.807967] Loading compiled-in X.509 certificates
[4.808742] Btrfs loaded, crc32c=crc32c-generic
[4.809731] mvebu-pcie soc:pcie: /soc/pcie/pcie@2,0: reset gpio is active low
[4.809763] mvebu-pcie soc:pcie: /soc/pcie/pcie@3,0: 

Re: [Nouveau] Problems getting nouveau to work with either Geforce GT710 or Geforce 9800GT on ARM Cortex-A9

[Luís Mendes]

The Geforce 9800GT also shows different behaviour without nvidiafb in
the kernel. I get lengthy messages from nouveau, like the ones found
in the email attachment.
It also eventually gets into the lightdm login graphical screen, but
with this card the screen is highly distorted, despite the mouse
cursor being properly displayed and moving around properly.

Luis

On Thu, Jan 25, 2018 at 1:14 PM, Luís Mendes  wrote:
> Hi Ben,
>
> Ok! I've removed nvidiafb from kernel config.
>
> Now linux is able to boot with the msi Geforce GT 710 card and
> eventually ends up displaying a slightly distorted lightdm login
> screen. The mouse cursor moves, but never changes to typing cursor
> mode when hovering the password input box, and I am also unable to
> enter the password, some graphics glitches in the login box too. There
> are warnings about semaphores problems in the logs.
> I believe one difference between this Cortex-A9 and Tegra SoCs is that
> the Cortex-A9 has no IOMMU.
>
> In attachment follows the boot log and the dmesg kernel log.
>
> Luís
#DMESG excerpt

Jan 25 13:16:36 localhost kernel: [6.279866] EXT4-fs (sda2): re-mounted. 
Opts: errors=remount-ro
Jan 25 13:16:36 localhost kernel: [7.669673] nouveau :01:00.0: enabling 
device (0140 -> 0143)
Jan 25 13:16:36 localhost kernel: [7.669780] nouveau :01:00.0: NVIDIA 
G92 (092a00a2)
Jan 25 13:16:36 localhost kernel: [7.781533] nouveau :01:00.0: bios: 
version 62.92.99.00.00
Jan 25 13:16:36 localhost kernel: [7.951654] nouveau :01:00.0: fb: 512 
MiB GDDR3
Jan 25 13:16:36 localhost kernel: [8.116784] [TTM] Zone  kernel: Available 
graphics memory: 512056 kiB
Jan 25 13:16:36 localhost kernel: [8.116788] [TTM] Initializing pool 
allocator
Jan 25 13:16:36 localhost kernel: [8.116797] [TTM] Initializing DMA pool 
allocator
Jan 25 13:16:36 localhost kernel: [8.116830] nouveau :01:00.0: DRM: 
VRAM: 512 MiB
Jan 25 13:16:36 localhost kernel: [8.116833] nouveau :01:00.0: DRM: 
GART: 1048576 MiB
Jan 25 13:16:36 localhost kernel: [8.116840] nouveau :01:00.0: DRM: 
TMDS table version 2.0
Jan 25 13:16:36 localhost kernel: [8.116844] nouveau :01:00.0: DRM: DCB 
version 4.0
Jan 25 13:16:36 localhost kernel: [8.116848] nouveau :01:00.0: DRM: DCB 
outp 01: 01011312 00020030
Jan 25 13:16:36 localhost kernel: [8.116852] nouveau :01:00.0: DRM: DCB 
outp 03: 02022322 00020010
Jan 25 13:16:36 localhost kernel: [8.116856] nouveau :01:00.0: DRM: DCB 
conn 00: 
Jan 25 13:16:36 localhost kernel: [8.116859] nouveau :01:00.0: DRM: DCB 
conn 01: 1130
Jan 25 13:16:36 localhost kernel: [8.116862] nouveau :01:00.0: DRM: DCB 
conn 02: 2261
Jan 25 13:16:36 localhost kernel: [8.158366] [drm] Supports vblank 
timestamp caching Rev 2 (21.10.2013).
Jan 25 13:16:36 localhost kernel: [8.158370] [drm] Driver supports precise 
vblank timestamp query.
Jan 25 13:16:36 localhost kernel: [8.192217] nouveau :01:00.0: DRM: MM: 
using CRYPT for buffer copies
Jan 25 13:16:36 localhost kernel: [8.272983] nouveau :01:00.0: DRM: 
allocated 1920x1080 fb: 0x7, bo 9b5dc40b
Jan 25 13:16:36 localhost kernel: [8.456001] Console: switching to colour 
frame buffer device 240x67
Jan 25 13:16:36 localhost kernel: [8.472590] nouveau :01:00.0: fifo: 
DMA_PUSHER - ch 1 [DRM] get 001200 put 001200 ib_get 0004 ib_put 
0005 state a0006610 (err: IB_EMPTY) push 00406040
Jan 25 13:16:36 localhost kernel: [8.472641] nouveau :01:00.0: fifo: 
DMA_PUSHER - ch 1 [DRM] get 001200 put 001200 ib_get 0005 ib_put 
0006 state a000 (err: IB_EMPTY) push 00406040
Jan 25 13:16:36 localhost kernel: [8.472687] nouveau :01:00.0: fifo: 
DMA_PUSHER - ch 1 [DRM] get 001200 put 001200 ib_get 0006 ib_put 
0007 state a000 (err: IB_EMPTY) push 00406040
Jan 25 13:16:36 localhost kernel: [8.472732] nouveau :01:00.0: fifo: 
DMA_PUSHER - ch 1 [DRM] get 001200 put 001200 ib_get 0007 ib_put 
0008 state a000 (err: IB_EMPTY) push 00406040
Jan 25 13:16:36 localhost kernel: [8.472777] nouveau :01:00.0: fifo: 
DMA_PUSHER - ch 1 [DRM] get 001200 put 001200 ib_get 0008 ib_put 
0009 state a000 (err: IB_EMPTY) push 00406040
Jan 25 13:16:36 localhost kernel: [8.472822] nouveau :01:00.0: fifo: 
DMA_PUSHER - ch 1 [DRM] get 001200 put 001200 ib_get 0009 ib_put 
000a state a000 (err: IB_EMPTY) push 00406040
Jan 25 13:16:36 localhost kernel: [8.472867] nouveau :01:00.0: fifo: 
DMA_PUSHER - ch 1 [DRM] get 001200 put 001200 ib_get 000a ib_put 
000b state a000 (err: IB_EMPTY) push 00406040
Jan 25 13:16:36 localhost kernel: [8.472912] nouveau :01:00.0: fifo: 
DMA_PUSHER - ch 1 [DRM] get 001200 put 001200 ib_get 000b ib_put 
000c state a000 (err: IB_EMPTY) push 00406040
Jan 25 

Re: [Nouveau] Problems getting nouveau to work with either Geforce GT710 or Geforce 9800GT on ARM Cortex-A9

[Luís Mendes]

Hi Ben,

Ok! I've removed nvidiafb from kernel config.

Now linux is able to boot with the msi Geforce GT 710 card and
eventually ends up displaying a slightly distorted lightdm login
screen. The mouse cursor moves, but never changes to typing cursor
mode when hovering the password input box, and I am also unable to
enter the password, some graphics glitches in the login box too. There
are warnings about semaphores problems in the logs.
I believe one difference between this Cortex-A9 and Tegra SoCs is that
the Cortex-A9 has no IOMMU.

In attachment follows the boot log and the dmesg kernel log.

Luís
#BOOT Log:

Starting kernel ...
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.15.0-rc8-next2g-gfd920f6-dirty (lpnm@ENIAC10) 
(gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #2 SMP Thu Jan 25 
12:44:50 WET 2018
[0.00] CPU: ARMv7 Processor [414fc091] revision 1 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Memory policy: Data cache writealloc
[0.00] random: fast init done
[0.00] percpu: Embedded 16 pages/cpu @(ptrval) s35212 r8192 d22132 
u65536
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 260096
[0.00] Kernel command line: root=/dev/sda2 rw rootfstype=ext4 rootwait 
console=ttyS0,115200n8
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 1023088K/1048576K available (11264K kernel code, 685K 
rwdata, 2296K rodata, 1024K init, 224K bss, 25488K reserved, 0K cma-reserved, 
0K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xc080 - 0xff80   (1008 MB)
[0.00] lowmem  : 0x8000 - 0xc000   (1024 MB)
[0.00] pkmap   : 0x7fe0 - 0x8000   (   2 MB)
[0.00] modules : 0x7f00 - 0x7fe0   (  14 MB)
[0.00]   .text : 0x(ptrval) - 0x(ptrval)   (12256 kB)
[0.00]   .init : 0x(ptrval) - 0x(ptrval)   (1024 kB)
[0.00]   .data : 0x(ptrval) - 0x(ptrval)   ( 686 kB)
[0.00].bss : 0x(ptrval) - 0x(ptrval)   ( 225 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[0.00] Hierarchical RCU implementation.
[0.00]  RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
[0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
[0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[0.00] L2C-310 erratum 769419 enabled
[0.00] L2C-310 enabling early BRESP for Cortex-A9
[0.00] L2C-310 full line of zeros enabled for Cortex-A9
[0.00] L2C-310 D prefetch enabled, offset 1 lines
[0.00] L2C-310 dynamic clock gating enabled, standby mode enabled
[0.00] L2C-310 Coherent cache controller enabled, 16 ways, 1024 kB
[0.00] L2C-310 Coherent: CACHE_ID 0x410054c9, AUX_CTRL 0x56070001
[0.06] sched_clock: 64 bits at 800MHz, resolution 1ns, wraps every 
4398046511103ns
[0.16] clocksource: arm_global_timer: mask: 0x 
max_cycles: 0xb881274fa3, max_idle_ns: 440795210636 ns
[0.29] Switching to timer-based delay loop, resolution 1ns
[0.000167] Ignoring duplicate/late registration of read_current_timer delay
[0.000174] clocksource: armada_370_xp_clocksource: mask: 0x 
max_cycles: 0x, max_idle_ns: 76450417870 ns
[0.000348] Console: colour dummy device 80x30
[0.000362] Calibrating delay loop (skipped), value calculated using timer 
frequency.. 1600.00 BogoMIPS (lpj=800)
[0.000368] pid_max: default: 32768 minimum: 301
[0.000416] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.000421] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.000655] CPU: Testing write buffer coherency: ok
[0.000769] CPU0: thread -1, cpu 0, socket 0, mpidr 8000
[0.000899] Setting up static identity map for 0x10 - 0x100060
[0.000972] mvebu-soc-id: MVEBU SoC ID=0x6828, Rev=0x4
[0.001046] mvebu-pmsu: Initializing Power Management Service Unit
[0.001095] Hierarchical SRCU implementation.
[0.002554] smp: Bringing up secondary CPUs ...
[0.002703] Booting CPU 1
[0.002856] CPU1: thread -1, cpu 1, socket 0, mpidr 8001
[0.002902] smp: Brought up 1 node, 2 CPUs
[0.002907] SMP: Total of 2 processors activated (3200.00 BogoMIPS).
[0.002910] CPU: All CPU(s) started in SVC mode.
[0.003327] devtmpfs: initialized
[0.005040] VFP support v0.3: implementor 41 architecture 3 part 30 variant 
9 rev 4
[0.005096] clocksource: jiffies: mask: 0x max_cycles: 0x, 
max_idle_ns: 1911260446275 ns
[0.005103] futex hash 

Re: [Nouveau] Problems getting nouveau to work with either Geforce GT710 or Geforce 9800GT on ARM Cortex-A9

[Luís Mendes]

Hi Ben,

Thanks for your reply.
My replies follow in between.

Luís

On Thu, Jan 25, 2018 at 5:40 AM, Ben Skeggs  wrote:
> On 24 January 2018 at 06:19, Luís Mendes  wrote:
>> Hi Arnd,
>>
>> Sorry for sending this email directly to you, but maybe you can help
>> me, or guide me where to look for.
>>
>> I am having big trouble getting the nouveau driver to work with either
>> Geforce GT 710 or Geforce 9800 GT on an ARM armv7l Cortex-A9 with PCIe
>> x1/x4 with linux kernel 4.15-rc.
>>
>> The Geforce GT 710 hangs the kernel boot process for a while and then
>> a kernel oops occurs, due to nvidiafb, when initializing CRTC. It also
>> generates messages "division by zero in kernel".
> You definitely want to disable nvidiafb somehow, it's ancient,
> unmaintained, and has zero chance of working on this hardware.  I'm
> not even entirely sure how/why it thinks it can work on this hardware,
> but just disable it.

I was unaware of that. I'll disable it and report back the results.

>
>>
>> The nouveau module generates a gpu lockup with Geforce 9800GT, DMA
>> transfers seem to fail, but sometimes is possible to start lightdm and
>> enter the login screen with an all black screen with just the mouse
>> cursor visible.
>>
>> I've also tried AMD RX460 and Radeon R7 240 graphics cards on the same
>> hardware with the same Linux kernel and I am able to enter Ubuntu Mate
>> 17.10 Desktop and run glmark and other applications, so I am sure the
>> hardware is capable of working with NVIDIA cards too, but the nouveau
>> module somehow doesn't cope well with the armv7l architecture, maybe
>> lock handling, irqs, dma fences, I don't know for sure.
> I'm not entirely sure what else is going on here.  Is that
> architecture big/little-endian?  We very likely have some issues on
> big-endian particularly with newer hardware, where the endian controls
> have either moved or disappeared.

I'm running Linux with ARM SoC in little endian mode (armv7l).

>
> The driver supposedly works on Tegra ARM architectures with PCIE
> devices, so hopefully there's not too much to do here to get it
> working for you.

Great! I appreciate any insight, or help you can give on this.

>
> Ben.
>
>>
>> I am a software and hardware engineer using Linux on a daily basis for
>> quite some time now, so that I am able to provide more details, try
>> patches, or make changes to kernel source to try to fix this, but I
>> would need some insight where to look for. Maybe you can help or
>> redirect me to someone who can help me...
>>
>> I've attached the kernel logs from both graphics cards issues.
>>
>> Regards,
>> Luís Mendes
>>
>> ___
>> Nouveau mailing list
>> Nouveau@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/nouveau
>>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] Problems getting nouveau to work with either Geforce GT710 or Geforce 9800GT on ARM Cortex-A9

[Luís Mendes]

Hi Arnd,

Sorry for sending this email directly to you, but maybe you can help
me, or guide me where to look for.

I am having big trouble getting the nouveau driver to work with either
Geforce GT 710 or Geforce 9800 GT on an ARM armv7l Cortex-A9 with PCIe
x1/x4 with linux kernel 4.15-rc.

The Geforce GT 710 hangs the kernel boot process for a while and then
a kernel oops occurs, due to nvidiafb, when initializing CRTC. It also
generates messages "division by zero in kernel".

The nouveau module generates a gpu lockup with Geforce 9800GT, DMA
transfers seem to fail, but sometimes is possible to start lightdm and
enter the login screen with an all black screen with just the mouse
cursor visible.

I've also tried AMD RX460 and Radeon R7 240 graphics cards on the same
hardware with the same Linux kernel and I am able to enter Ubuntu Mate
17.10 Desktop and run glmark and other applications, so I am sure the
hardware is capable of working with NVIDIA cards too, but the nouveau
module somehow doesn't cope well with the armv7l architecture, maybe
lock handling, irqs, dma fences, I don't know for sure.

I am a software and hardware engineer using Linux on a daily basis for
quite some time now, so that I am able to provide more details, try
patches, or make changes to kernel source to try to fix this, but I
would need some insight where to look for. Maybe you can help or
redirect me to someone who can help me...

I've attached the kernel logs from both graphics cards issues.

Regards,
Luís Mendes
Starting kernel ...
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.15.0-rc4-next2g-g400b6af-dirty (lpnm@ENIAC10) 
(gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #2 SMP Sun Jan 21 
11:08:49 WET 2018
[0.00] CPU: ARMv7 Processor [414fc091] revision 1 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Memory policy: Data cache writealloc
[0.00] random: fast init done
[0.00] percpu: Embedded 16 pages/cpu @(ptrval) s35148 r8192 d22196 
u65536
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 260096
[0.00] Kernel command line: root=/dev/sda2 rw rootfstype=ext4 rootwait 
console=ttyS0,115200n8
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 1023088K/1048576K available (11264K kernel code, 685K 
rwdata, 2296K rodata, 1024K init, 224K bss, 25488K reserved, 0K cma-reserved, 
0K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xc080 - 0xff80   (1008 MB)
[0.00] lowmem  : 0x8000 - 0xc000   (1024 MB)
[0.00] pkmap   : 0x7fe0 - 0x8000   (   2 MB)
[0.00] modules : 0x7f00 - 0x7fe0   (  14 MB)
[0.00]   .text : 0x(ptrval) - 0x(ptrval)   (12256 kB)
[0.00]   .init : 0x(ptrval) - 0x(ptrval)   (1024 kB)
[0.00]   .data : 0x(ptrval) - 0x(ptrval)   ( 686 kB)
[0.00].bss : 0x(ptrval) - 0x(ptrval)   ( 225 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[0.00] Hierarchical RCU implementation.
[0.00]  RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
[0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
[0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[0.00] L2C-310 erratum 769419 enabled
[0.00] L2C-310 enabling early BRESP for Cortex-A9
[0.00] L2C-310 full line of zeros enabled for Cortex-A9
[0.00] L2C-310 D prefetch enabled, offset 1 lines
[0.00] L2C-310 dynamic clock gating enabled, standby mode enabled
[0.00] L2C-310 Coherent cache controller enabled, 16 ways, 1024 kB
[0.00] L2C-310 Coherent: CACHE_ID 0x410054c9, AUX_CTRL 0x56070001
[0.06] sched_clock: 64 bits at 800MHz, resolution 1ns, wraps every 
4398046511103ns
[0.16] clocksource: arm_global_timer: mask: 0x 
max_cycles: 0xb881274fa3, max_idle_ns: 440795210636 ns
[0.30] Switching to timer-based delay loop, resolution 1ns
[0.000164] Ignoring duplicate/late registration of read_current_timer delay
[0.000170] clocksource: armada_370_xp_clocksource: mask: 0x 
max_cycles: 0x, max_idle_ns: 76450417870 ns
[0.000341] Console: colour dummy device 80x30
[0.000353] Calibrating delay loop (skipped), value calculated using timer 
frequency.. 1600.00 BogoMIPS (lpj=800)
[0.000360] pid_max: default: 32768 minimum: 301
[0.000407] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.000413] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.000648] CPU: Testing write buffer coherency: ok