01:11voxadam_: I just built a custom kernel but when I boot my machine all I see is a blank screen. I was using the proprietary nvidia drivers but I've switched back to nouveau.
01:11voxadam_: I've changed my xorg.conf and grub2 configuration.
01:18pmoreau: voxadam_: Did you try Nouveau with a stock kernel first, or did you jumped directly to a custom kernel?
01:18pmoreau: What card do you have, and which kernel version are you using?
01:20voxadam_: pmoreau: Sorry. It's a 3.18.7 kernel and no, I haven't tried a stock Fedora kernel.
01:21voxadam_: I do know that it's booting properly. I can ssh into it.
01:22pmoreau: Which card is it?
01:24voxadam_: An old 550Ti
01:25RSpliet: old :D
01:26voxadam_: I just reinstalled the distro kernel.
01:26voxadam_: I'm rebooting now.
01:26voxadam_: RSpliet: I'm not a gamer. I don't need a card that costs a grand on my machines.
01:27voxadam_: And yea... I know what old is.
01:27RSpliet: voxadam_: I've just been hacking away on a GTX260, I wish I had something that new :p
01:27RSpliet: but don't worry, I'm just joking
01:27voxadam_: It's all about perspective.
01:28voxadam_: I rember the days when AGP was hot sh|t.
01:28RSpliet: oh yes... my first card was an FX 5600
01:28voxadam_: Actually... I rember local bus.
01:28RSpliet: died a horrible death
01:28voxadam_: Voodoo or die!
01:29RSpliet: it was fanless for two years, not by design
01:29voxadam_: not bad.
01:29RSpliet: anyway, bbl. Good luck with your 550Ti, I hope you figure out what's wrong :-)
01:30voxadam_: I'm sure it's something obvious
01:33pmoreau: If you can SSH in, could you get the dmesg please?
01:53voxadam_: pmoreau: http://fpaste.org/195066/42580837/
01:55pmoreau: Do you happen to have `blacklist nouveau` somewhere (look in /etc/modprobe.conf or /etc/modprobe.d/*.conf)? Cause I can't see Nouveau loading at all! :D
01:55pmoreau: Or maybe nomodeset, or nouveau.modeset=0
01:56voxadam_: I did have modset=0 but I edited the kernel params in grub when booting.
01:57voxadam_: My /proc/cmdline is "BOOT_IMAGE=/vmlinuz-3.18.7-200.voxadam.fc21.x86_64 root=UUID=ed9ac6fa-7850-4162-a2b5-2b3fd3dcbc5f ro rootflags=subvol=root vconsole.font=latarcyrheb-sun16 LANG=en_US.UTF-8 video=vesa:off"
01:58pmoreau: If you boot with `nouveau.modeset=0` to disable Nouveau and only use i915, do you get something on screen?
03:00pmoreau: No idea what those ACPI warnings means: "[ 14.441782] ACPI Warning: SystemIO range 0x00000000000008b0-0x00000000000008bf conflicts with OpRegion 0x00000000000008b8-0x00000000000008b8 (\GHI0)"
03:01voxadam_: I haven't tiried booting to my integrated adapter.
03:02voxadam_: Give me a few.
03:02pmoreau: And there is those drm messages: "[ 6.304086] [drm] Setting output timings on SDVOB failed", but again, no idea what it means.
03:02voxadam_: You and me both.
03:03voxadam_: I've read kernel messages for years but I' not clear on those.
03:03voxadam_: I should search the source.
03:05voxadam_: pmoreau: If I set `nouveau.modeset=0` should I be attached to my nv card or the integrated Intel adapter?
03:07pmoreau: Try attaching to the NVidia card, we'll see if the default fb driver manages to get something on screen. Remove the `video=` parameter, just in case.
03:10voxadam_: It boots just fine and I can still ssh but there's no apparent change.
03:10voxadam_: 'BOOT_IMAGE=/vmlinuz-3.18.7-200.voxadam.fc21.x86_64 root=UUID=ed9ac6fa-7850-4162-a2b5-2b3fd3dcbc5f ro rootflags=subvol=root vconsole.font=latarcyrheb-sun16 rhgb quiet LANG=en_US.UTF-8 nouveau.modeset=0 video=vesa:off
03:12pmoreau: Hum... Try loading Nouveau manually with "modprobe nouveau modeset=1"
03:13voxadam_: Not even any messages in dmesg.
03:13pmoreau: Does lsmod returns nouveau?
03:14voxadam_: It's loaded.
03:14voxadam_: I knoe.
03:14voxadam_: I hate this keyboard.
03:16pmoreau: imirkin, skeggsb, mlankhorst: Do you have any idea on what is going wrong? -^
03:16voxadam_: As much as I *really* want to solve this puzzle right now, it's 0315 here and I have to work in the morning.
03:16voxadam_: I'm going to have to come back to this tomorrow/
03:16pmoreau: i understand
03:17pmoreau: See you then!
03:17voxadam_: This box will not win!
03:17voxadam_: I will prevail!
03:17voxadam_: Thanks for your help pmoreau
03:17pmoreau: You're welcome!
09:04hjanos_: I'm Janos
09:04hjanos_: I have a few questions about the Maxwell Accelerated Video Decoding GSoC project
09:08hjanos_: I have a basic understanding of reverse engineering
09:08hjanos_: but I don't have much video format experience
09:10hjanos_: Can I learn the video format knowledge required for this project if I have not much previous experience with it?
09:32imirkin: hjanos_: sure... it was just a random keyword i put in there. knowing the h264 format off the top of your head is hardly required
09:32imirkin: however as part of it, you will end up needing to learn a bunch about the relevant video formats
09:32imirkin: some of the info you'll be able to get here, but some will have to come from self-learning
09:33hjanos_: imirkin: I'm generally a quick learner, so that should not be a problem given that learning materials are available
09:35hjanos_: imirkin: Can you link an example of what I would need to learn?
09:40imirkin: hjanos_: hmmm... looks like some of the things i wrote didn't get to you... see pm
22:43twohot: nice. So there is a nouveau channel
22:44twohot: Good morning everyone
22:44twohot: Any idea what might be causing this: https://bugzilla.redhat.com/show_bug.cgi?id=1197489
22:47skeggsb: twohot: the x crash doesn't even look related to graphics to me
22:48imirkin: seems like some sort of bug in Xorg 1.17
22:49skeggsb: the dmesg warning is our bug, and one i've seen reported a few times now, but i have nfi what's causing that, nor have i ever seen it myself
22:49imirkin: what's 2140?
22:49imirkin: that's unfortunate
22:50skeggsb: so, it should definitely exist.. i suspect something nasty with runtime pm is most likely
22:50imirkin: it's right after the card is woken up
22:50imirkin: so some sort of sync? dunno
22:50skeggsb: missing delays of some kind perhaps, no idea
22:50imirkin: skeggsb: btw, did you see this? https://bugs.freedesktop.org/show_bug.cgi?id=89484
22:51skeggsb:wonders exactly which script we're trying to run there
22:52skeggsb: oh, the vbios image is there.. let me find out
22:53twohot: anything you guys need to track down this bug, let me know and I'll try to grab it
22:54skeggsb: twohot: i'm pretty sure the issue you actually care about isn't our bug
22:54twohot: twohot: okay. I will look again
22:56skeggsb: imirkin: ugh, annoying
22:59imirkin: using an opcode before the modeset happens?
22:59skeggsb: using one that requires a head index in a place we never have before, and actually *can't* because we don't know necessarily have a head attached at the time
23:00skeggsb: it's in the dp link training power-up script
23:01imirkin: why is it running that dp link training script?
23:01skeggsb: because we train the link first, so we know available bandwidth for mode validation...
23:02skeggsb: it would be interesting to see a mmiotrace of the binary driver there
23:03skeggsb: imirkin: also, airlied tells me that for mst we probably need to have a trained link before doing anything too, so, it seems a bit odd
23:04imirkin: hmmm... well can't you get all the stuff over the aux channel first?
23:04imirkin: although actually
23:04imirkin: why does it need a head?
23:04imirkin: it shouldn't, right?
23:05skeggsb: it shouldn't no, and i've never seen a vbios have that write in that script
23:05skeggsb: iirc, the U table scripts usually do a copy from the SOR version of that reg into the DP block version of it
23:06skeggsb: this training script tries to reset both to the same value
23:07Leftmost: I think the next step for ARB_copy_image is going to be a new flag to blit, after thinking through it. The copy needs to be aware of memory layout but also not attempt to reinterpret, so it's a blit flag or a whole new function.
23:08imirkin: skeggsb: i like the second init script :)
23:09imirkin: er wait. i'm looking at the wrong thing
23:10imirkin: nvbios doesn't like that vbios at all =/
23:11skeggsb: there does seem to be some things horribly wrong with it, yes
23:12imirkin: -p scripts makes it go
23:12skeggsb: i suspect it was taken from the pci rom, where it's been stomped all over
23:13imirkin: so what's the problem? that DP_CONDITION thing?
23:13skeggsb: hrm, that'd be odd though.. we get it from ACPI
23:14imirkin: Failed to parse CONN table at 0x5541 version 0.0
23:14skeggsb: we parse it fine in nouveau, that image is bad
23:16skeggsb: imirkin: it's the script that starts at 0x5c52, instruction at 0x5c79 (INIT_NV_REG 0x616600+(head*0x800) 0xFFFFBFFE 0x00004001)
23:18imirkin: why does it say nouveau E[ VBIOS][0000:01:00.0] 0x5c86: script needs crtc then?
23:19skeggsb: because of the (head*0x800) part
23:19skeggsb: 0x6166xx is the DP block, which is per-head
23:19imirkin: right, but that's 5c86
23:19imirkin: not the offsets you're mentioning
23:19imirkin: 0x5c79: 6e 00 66 61 80 fe bf ff ff 01 40 00 00 NV_REG R[0x80616600] &= 0xffffbffe |= 0x00004001
23:19imirkin: 0x5c86: 6e 00 23 61 40 ff ff ff fc 00 00 00 03 NV_REG R[0x40612300] &= 0xfcffffff |= 0x03000000
23:20skeggsb: yeah, we've already read the opcode data at that point, so the pointer is pointing at the next instruction
23:20imirkin: ah :)
23:20skeggsb: that could probably be considered a minor bug on its own i guess, but, meh
23:21imirkin: yeah, a tad misleading...
23:22skeggsb: i'm not too sure what would be the best option to fix this, but i'd definitely like to see what nvidia do
23:50imirkin: skeggsb: would there be harm in just doing it to head 0 if there isn't one?
23:50imirkin: or perhaps skipping the write
23:50skeggsb: well, all we do currently is skip it actually
23:51skeggsb: head 0 is dangerous though, we could have a mode programmed on it already
23:51imirkin: are you sure? i assumed we aborted
23:51skeggsb: i'm pretty sure we only abort for invalid opcodes (and only because we have no idea where the next one will be in that case)
23:51imirkin: ah yeah, you're right, it just keeps going
23:52imirkin: and does it on head 0 :)
23:52imirkin: the later scripts have similar errors:
23:52imirkin: [ 39.545434] nouveau E[ VBIOS][0000:01:00.0] 0x62d3: script needs connector type
23:52imirkin: [ 39.575373] nouveau E[ VBIOS][0000:01:00.0] 0x5c86: script needs crtc
23:52skeggsb: the connector-related bios warning is worrying though.. we only ever run that script in one place (after POST)
23:52skeggsb: and it works the first time..
23:53skeggsb: i have nfi why it fails for subsequent runs (guessing those are from runpm)
23:54skeggsb: it's entirely possible those warnings aren't related to why it's failing too.. so, i think at this point we need to ask for a) mmiotrace, and b) nouveau.debug=pdisp=trace,vbios=trace