12:31mntmn: hey i have a bit exotic setup here with an i.mx6q (arm cortex a9) and a NVIDIA Corporation GK208 [GeForce GT 710B] (rev a1) (prog-if 00 [VGA controller])
12:31mntmn: i get > nouveau 0000:01:00.0: unknown chipset (e59ff01c)
12:32mntmn: anything i could try or lost cause?
12:32tomeu: "a bit"
12:32mntmn: hehe tomeu
12:34mntmn: the question is more like: is this graphics chip supported and should normally work, i.e. it's an arm/synopsys problem?
12:35imirkin: mntmn: something seems off with MMIO
12:35imirkin: that's not a correct value for the chipset id
12:35imirkin: and if reading that fails, then all bets are off
12:36imirkin: there's a pci-level issue
12:36mntmn: ah, gotcha. what should normal values look like?
12:36imirkin: does the board itself have a PCIe slot, or are you doing something clever?
12:36mntmn: imirkin: i'm using an mPCIE to PCIe 1x adapter (the card is 1x)
12:36imirkin: well, you're not well placed to identify valid vs invalid values
12:37imirkin: if it were super-invalid, it'd read ffffffff -- pci is active-low, so "zeros" are actually all one's
12:37imirkin: this value means the read semi-succeeded
12:37imirkin: but not enough to actually get a correct value
12:38imirkin: could be that the BAR setup is wrong, could be some cache coherency issue (i don't trust ARM)
12:38imirkin: GK208 is fairly well supported
12:38karolherbst: mntmn: is this one of those super cheap mpcie to pcie adapters?
12:39imirkin: does the adapter have its own power source?
12:39mntmn: karolherbst, yeah, it's basically just a short flatband cable
12:39mntmn: imirkin: yes
12:39imirkin: iirc the TDP of GK208's is in the 30W range
12:39karolherbst: imirkin: the power source isn't the problem here
12:39mntmn: yeah i have 2 external power supplies for it
12:39mntmn: i also designed the motherboard
12:39karolherbst: mntmn: what can happen is, that the PCIe signal is too weak to be stable enough though
12:39imirkin: (which would be about 30W more than the i.mx6 can provide)
12:40mntmn: (but i put mPCIe on it instead of PCIe)
12:40karolherbst: mntmn: do you know if that adapter works in practice?
12:40imirkin: yeah, i'd try plugging a NIC in if you have one available
12:40karolherbst: like does it work with an ethernet card or something else
12:40imirkin: or something else innocuous
12:41mntmn: karolherbst, hmm i have only tried a radeon card that doesn't work because it wants to map too big BARs
12:41karolherbst: maybe the BARs are too big because of the cable as well ;)
12:41mntmn: (this soc can only map 16 MB of PCIe space, but i don't get any errors with the nvidia card vs the radeon)
12:41karolherbst: who knows what random bit flips might happen
12:42imirkin: mntmn: ooh.... only 16MB of PCIe?
12:42imirkin: that is not gonna go over well.
12:42mntmn: karolherbst, yeah but OTOH i heard that radeon wants to map a huge amount of vram like that
12:42mntmn: imirkin, yeah it's kinda sad
12:42imirkin: so .... i think the BAR's are actually configurable
12:42imirkin: (i mean a configurable size)
12:43imirkin: but nouveau does not support this directly iirc
12:43mntmn: yeah that was kinda the straw i'm clinging on
12:43imirkin: iirc all the "interesting" stuff happens on BAR3, which on my GF108 is Region 3: Memory at de000000 (64-bit, prefetchable) [size=32M]
12:43karolherbst: imirkin: nouveau also reads out the chipset from 0x0, right?
12:43karolherbst: mntmn: lspci is happy though?
12:43imirkin: karolherbst: yeah. but ... where is 0x0 ;)
12:44mntmn: maybe it doesn't work in a 32 bit system?
12:44karolherbst: mntmn: is the GPU at 01:00.0?
12:44imirkin: mntmn: https://envytools.readthedocs.io/en/latest/hw/bus/bars.html
12:44karolherbst: or some other address?
12:45mntmn: karolherbst: yep 01:00.0
12:45imirkin: i was wrong - BAR0 is the "main" BAR.
12:45mntmn: lspci lists 3 mappings, two of them disabled
12:45imirkin: which for me is sized to 16M
12:45mntmn: 2x > Memory at <unassigned> (64-bit, prefetchable) [disabled]
12:45mntmn: and > I/O ports at 1000 [size=128]
12:45imirkin: can you pastebin the lspci output?
12:45karolherbst: mntmn: lspci -s 01:00.0 -vv -xxx
12:46imirkin: are there funny pci errors when you load nouveau?
12:46mntmn: imirkin: nope
12:47karolherbst: the pci config space looks fine
12:47karolherbst: but yeah Region 1/3
12:49imirkin: that is not find.
12:49karolherbst: and no Region 0?
12:49imirkin: yeah, where's region 0
12:49mntmn: dmesg has only 1 entry for this card: > [ 0.465770] pci 0000:01:00.0: BAR 0: assigned [mem 0x01100000-0x0110ffff 64bit]
12:49imirkin: the most important of them all
12:50imirkin: that is not 16MB
12:50imirkin: that's 64KB
12:50karolherbst: mntmn: I have something like that in lspci: Region 0: Memory at ec000000 (32-bit, non-prefetchable) [size=16M]
12:50mntmn: ah strange
12:50karolherbst: and pci 0000:01:00.0: BAR 0: assigned [mem 0xec000000-0xecffffff] in dmesg
12:51imirkin: but even if you map it in, i'm not sure that nouveau can operate with *only* BAR0 mapped
12:52imirkin: anyways, you need to figure out these PCI issues before nouveau will work
12:52mntmn: ok, gotcha
12:53karolherbst: mntmn: why is that by the way? "Link: Gen2 disabled"
12:53imirkin: the bridge window is only 1MB too?
12:53imirkin: anyways, this is all above my pay-grade. you'll have to find someone who speaks pci to make sense of all this.
12:53mntmn: good question, let me see karolherbst
12:53mntmn: imirkin: ok, thank you anyway :)
12:54karolherbst: mntmn: newer cards usually come up in v2 mode, but I think they should just do fine dropping to v1 if the host doesn't support it
12:54karolherbst: allthough I could imagine it is untested on newer cards
12:56mntmn: karolherbst, gen2 speed needs an external oscillator, it can be enabled in DTS but the documentation says that the SoC clock itself has too much jitter to meet the spec of gen2
12:56karolherbst: mntmn: okay, shouldn't matter that much anyway.
12:56mntmn: yeah but well spotted
12:56imirkin: mntmn: fwiw we could probably get away with just 8MB of BAR0 in practice
12:56karolherbst: just not sure if it works or not, allthough i just should
12:56imirkin: i don't think there are any mmio addresses above 0x700000
12:57karolherbst: I know that the GPUs operate just fine if put into v1 mode, but....
12:57mntmn: yeah who knows
12:57karolherbst: imirkin: there are actually
12:58imirkin: that are actively used by the driver?
12:58karolherbst: ohh wait, you mean 0x800000 actually, or not?
12:58imirkin: well, whatever.
12:58imirkin: oh right. 0x700000 is RAMIN :)
12:59mntmn: is BAR0 the register space?
12:59mntmn: ah yeah i should rtfm
12:59imirkin: mntmn: kinda. not really register so much as function call...
12:59karolherbst: imirkin: nouveau/nvkm/subdev/bios/shadowramin.c
12:59karolherbst: but yeah...
12:59sigod: i was just wondering if the developer who had a gtx660 has done a trace yet re the context switch error?
12:59karolherbst: I guess you can just not use that
13:00imirkin: karolherbst: still doesn't go over 0x800000 which is 8MB
13:00karolherbst: sigod: there is a trace
13:00karolherbst: imirkin: right
13:01karolherbst: sigod: but afaik the trace didn't show anything useful
13:01sigod: oh ok
13:01karolherbst: I actually have access to that card, but I didn't really do much with it yet, cause I was occupied a bit
13:01karolherbst: I might try to figure something out next week though
13:02karolherbst: I think I found a way to trigger it quite fast
13:02sigod: yea it takes a while to crash x
13:02karolherbst: well, I got an error after a few seconds by spamming glxspheres64
13:02karolherbst: got like 20 of them running
13:02sigod: yea or a heavy 3d app
13:03karolherbst: yeah, maybe
13:03sigod: yea not sure either
13:03karolherbst: but can you verify, that spamming glxspheres64 kind of triggers it?
13:03karolherbst: allthough I noticed that the desktop recovered when I killed all of those via ssh
13:03sigod: yea you can still access via ssh
13:04sigod: but i couldnt recover x
13:04karolherbst: well, I will try to figure something out then
13:04karolherbst: could be anything though and maybe I don't find anything
13:06sigod: it seems like a specific problem though like the management acceleration between different applications or is it deeper than that
13:07karolherbst: does the nvidia firmware helps?
13:07karolherbst: if it is a bug simply inside our firmware, it might be able to track it down
13:07sigod: i cant test that because im using parabola
13:08sigod: yea i think it is the nouveau firmware maybe
13:08karolherbst: maybe it is a stupid bug like we get a value we don't expect and forget to mask values or something silly like this
13:08karolherbst: who knows
13:09sigod: isnt the nvidia firmware just for the video decoding etc
13:09sigod: i mean nouveau-fw
13:09karolherbst: right, but user can also use the nvidia context switching code
13:11sigod: so nouveau has its own firmware for the various cpus on the board?
13:11karolherbst: allthough you wouldn't call them CPU
13:19imirkin: karolherbst: i would.
13:19imirkin: they're CPUs
13:19imirkin: they run an OS
13:19imirkin: simple though it might be
13:20imirkin: sigod: while most of the userful firmware extracted by my script is for video decoding, i also extended to grab the ctxsw fw
13:20imirkin: sigod: see https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware for instructions
13:22sigod: yea thanks but remember im on parabola
13:22imirkin: dunno what that means
13:22imirkin: is that like x^2?
13:23karolherbst: imirkin: libre kernel
13:23imirkin: you know, all this "libre kernel" bs is ... bs.
13:23imirkin: we should just move the nouveau-made firwmare into linux-firmware
13:23imirkin: and move on with life.
13:24imirkin: why is loading firmware off disk so wrong
13:24karolherbst: I guess you can't prevent loading firmware off chip anyway
13:24karolherbst: I am sure the libre linux kernel would even try to do this
13:24orbea: non-free blobs that can be seen are evil and non-free blbos you cant see are fine? :P
13:25imirkin: orbea: what about free blobs that happen to be sitting on your hard drive?
13:25imirkin: and not *built into the kernel*
13:25karolherbst: imirkin: but yeah, maybe we should just move it into linux-firmware and load the firmware from there
13:25sigod: they arent in use
13:25karolherbst: imirkin: easier to update
13:25sigod: ideally you wouldnt have non-free blobs sitting there
13:26sigod: on the os anyway
13:26karolherbst: well practically you shouldn't turn on your computer if you care for real
13:26imirkin: and wear a tinfoil hat
13:26sigod: with the non-free bios
13:26karolherbst: the CPU is already the problem
13:26karolherbst: and ethernet cards
13:26karolherbst: and wifi cards
13:27imirkin: anyways, what i'm against here, btw, is how the "libre kernel" implements its policy
13:27karolherbst: the usual way of doing things is to have embedded firmware and be able to update it via firmware blobs on hardware
13:27imirkin: i'm all for removing non-free blobs from kernel
13:27karolherbst: so in this case, preventing loading firmware might even reduce system security
13:27karolherbst: *on disc
13:28imirkin: sigod: either way, you won't get much support or sympathy for running a lobotomized kernel
13:28sigod: its just a non-negotiable thing
13:28orbea: s/non-negotiable/placebo/ :P
13:29sigod: im not after sympathy i dont want to be a pain though
13:29imirkin: i would actually strongly support making sure nouveau can't run on such kernels even with our own firmware
13:29karolherbst: imirkin: and how would you do that :p
13:29imirkin: by moving our firmware to linux-firmware
13:29karolherbst: doesn't change it
13:30imirkin: then request_firmware() would be required
13:30karolherbst: because our firmware is still free software
13:30karolherbst: they would have to fix it :)
13:30karolherbst: and add whitelists/blacklists
13:30imirkin: making them jump through more hoops to support their idiocy sounds like a reasonable outcome.
13:30karolherbst: we just have to care about stable interfaces then
13:30karolherbst: and maybe even versioning
13:31imirkin: that's indeed unfortunate.
13:31karolherbst: what if we add new interfaces to our PMU firmware
13:31karolherbst: anyway, it isn't something we could just do without it being painful in the future if we don't do it correctly
13:31sigod: im on a laptop with intel gfx atm and it works perfectly
13:31sigod: its just for my desktop
13:32orbea: there is non-free stuff in the intel cpus, no?
13:32sigod: no the specs are available
13:33karolherbst: orbea: you have to ask differently: is there something with non free stuff?
13:33karolherbst: I meant is there something with no non free stuff
13:34orbea: yea, wouldn't be surprised if there if other stuff had soething non-free in the hardware.
13:34karolherbst: sigod: well you also need blobs for newer intel chips kind of
13:34karolherbst: orbea: hardware itself is usually non-free ;)
13:35sigod: yea thats why people are building free hardware 3d printed computers
13:35orbea: i certainly wish there was more freedom in hardware, but libre-linux doesn't seem like a solution as much as sticking your head underwater until you drown
13:36imirkin: sigod: starting with later intel chips, you have to load various firmware off disk. but all intel cpu's since p4 have tons and tons and tons of firmware all around.
13:36sigod: yea same with amd
13:36karolherbst: and their minix kernel....
13:37imirkin: (later = skylake iirc)
13:37karolherbst: I never thought anybody would use minix in production
13:37karolherbst: but intel does
13:37sigod: yea i have an i7 950 and it doesnt have the Intel management engine
13:37imirkin:has i7-920 :)
13:38karolherbst: it still has something though, right?
13:38imirkin: sure. tons of stuff.
13:38karolherbst: also minix?
13:38mntmn: imx6 doesn't need to load any firmware btw ;) but it can't talk to nvidia chips over pcie it seems :|
13:38sigod: motherboard is a gigabyte x58udr3 v2
13:39sigod: going strong for 8 years
13:39imirkin: sigod: i guess it was a popular board at the time
13:39imirkin: Manufacturer: Gigabyte Technology Co., Ltd.
13:39imirkin: Product Name: EX58-UD3R
13:40karolherbst: ohh they used ThreadX RTOS before minix anyway
13:40sigod: it has this annoying whine though that everyone complained about and gigabyte didnt fix i updated the bios and it didnt change anything
13:40imirkin: mmmm... haven't noticed it. i think i have other loud things though.
13:40sigod: i thought it was my psu but im pretty sure its the mb
13:40imirkin: not to mention hearing loss due to a decade of nyc subways
13:41sigod: thats no good
13:41sigod: you are brave to live in nyc
13:42imirkin: ... ok
13:42sigod: i mean with all the people
13:42imirkin: as opposed to other places, which don't have people?
13:42sigod: rats etc
13:42imirkin: yummy delicious rats!
13:42sigod: pizza rat
13:43imirkin: nyc doesn't have that many rats
13:43imirkin: boston - now that's a city with rats
13:43imirkin: and they get a lot more motivated to go inside during winter
13:43karolherbst: It never occured to me, but I figure you really have alot of rats over there?
13:44imirkin: in nyc? not really. you see them in the subway, but rarely on the streets, and almost never in houses
13:44imirkin: sigod: right. but that's just like 1
13:45karolherbst: proven by sample size of 1!
13:45imirkin: proof by induction...
13:45imirkin: it's true for n = 1, therefore it's true for all n
13:45karolherbst: well you hav eto proove it is true for n + 1 as well ;)
13:46imirkin: it was a joke.
13:46imirkin: one of the various "ways to prove it". including things like "proof by handwaving"
13:50orbea: nice link :)
13:50sigod: dont worry we have 30 million possums in nz
13:50sigod: and only 4 million people
13:50imirkin: not sure i even know what a possum is... definitely heard the name, but not sure i've ever seen one in person
13:51imirkin: oh. a super-furry rat.
13:51orbea: As a biologist I was taught that science doesn't prove anything as much as it explains observations. :)
13:51orbea: also possums are not in North America, not suprising you wouldn't see one. We do have opposums though :P
13:52imirkin: they look a lot meaner in google images results
13:52karolherbst: orbea: correct
13:52imirkin: The largest are the two species of bear cuscus which may exceed 7 kg (15 lb 7 oz).
13:52imirkin: holy crap that's big
13:53karolherbst: orbea: "science" is just a way of doing things anyway. and whatever you come up with while doing "science" ist merely a try to explain how things are by never really saying how things are for real ;)
13:54imirkin: karolherbst: sounds like something for the devil's dictionary
17:22mooch: hey, does anybody have any idea what the NV21 GPU referenced in this commit is? https://github.com/skeggsb/nouveau/commit/577d928b9d8ce48cdc52812b9b9bd408c5d963e3#diff-1360a25122ce3ff9d96636b148094d5b
17:22mooch: oh wait
17:23mooch: i'm an idiot, sorry
17:23imirkin_: like NV12 but backwards.