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