03:02imirkin: nyef`: what's the relevance of "subpack" - e.g. why is it subpack0/1 and high/low?
03:05gnarface: is there a way to force nouveau to use a specific IRQ? i've been trying to track down a regression between kernel 3.2 and kernel 3.16 (debian stable) and i'm starting to suspect the problem is that on the later kernel it uses the same irq as the ethernet device or soundcard
03:05imirkin: gnarface: irq assignment is done by the pci subsystem
03:06gnarface: imirkin: does that mean that i can only change it if my bios has that feature?
03:06gnarface: (it doesn't, in this case - stupid useless dell bios)
03:07imirkin: it means that it's not nouveau that assigns the irq
03:07imirkin: but rather the linux pci subsystem
03:07imirkin: i have no idea what the logic is there
03:07gnarface: ok, thanks for the info
03:07imirkin: gnarface: note that starting with kernel ... something old, nouveau has started to use MSI interrupts
03:07imirkin: if your system supports them
03:07imirkin: remind me what your GPU is?
03:08gnarface: its this old g92 card we talked about previously. the one that i was trying to load the non-free firmware into for hardware video acceleration
03:08gnarface: but that's not the only thing i'm doing with this system
03:08gnarface: in fact, in this particular case, the video card should not even be used at all
03:09gnarface: which makes it doubly weird to me
03:09gnarface: that it would be a problem at all
03:09gnarface: but i can clearly see it uses a different IRQ on 3.16 than 3.2, so maybe its the MSI interrupts you're talking about
03:10gnarface: (nothing else's irq seemed to change)
03:24mwk: *sigh* why cannot readthedocs find my pretty PGRAPH diagram
03:47AndrewR: so, if I want to find out current vdec frequency (on nv92) I need to read PCONTROL (0xc000) and PCLOCK (0x4000) with various offsets with nvapeek, and calculate it 'by hand', right
03:50imirkin: sounds right
03:50imirkin: you think that maybe the vdec clocks are off on boot for G92?
03:50imirkin: note that vdec is part of the whole PCRYPT engine
03:51imirkin: that doesn't mean they have to share clocks, but probably do.
03:54AndrewR: imirkin, I think it somewhat slow for decoding mpeg2 ...I have 4.10-rc3 kernel with manually allowed reclocking for nv92, but I'm not sure if vdec freq reset every time by kernel/hwseq script, as it seems to be for core/shader (mem still not reclockable, but this is bigger/harder for me problem)
03:54imirkin: AndrewR: doesn't vdec hang on G92?
03:55imirkin: or are you using PMPEG?
03:55imirkin: or is it only H.264 (i.e. PBSP) usage which kills it?
03:56AndrewR: right now I run into counting poblem ( you can laugh). result for nvapeek was 0000c040: 2c801c33 and by inserting it into kcalc I got "101100100000000001110000110011" . Hm, a bit too little number of bits ...??
03:56imirkin: >>> bin(0x2c801c33)
03:56imirkin: seems right
03:57imirkin: note that the LSB is on the right
03:57mwk: IIRC we never figured out what clock the VP2 PCRYPT runs off
03:57imirkin: and that any 0 MSB's aren't printed
03:57AndrewR: I can use vp2/bsp for mpeg2 (superslow), or yes, NOUVEAU_PMPEG with much better speed, still not realtime for dreamtime.mpg (mpeg2, 720p 60 fps)
03:57imirkin: AndrewR: but h264 hangs, right?
03:58AndrewR: imirkin, yah, still hangs (checked yesterday with this new kernel/mesa)
03:58imirkin: fwiw PBSP only supports h264 on vp2 chips - mpeg2 only gets partial accel
03:58imirkin: i.e. only PVP
03:59AndrewR: hm, so it was PBSP hanging?
03:59imirkin: that seems likely.
04:03mwk: well that was fucking dumb.
04:03mwk: I suppose now my diagram will render correctly.
04:04imirkin: oops :)
04:04mwk: and I spent half an hour debugging this
04:05imirkin: mwk: fyi, i have a GK208B plugged in, if you want me to read any values out of it
04:05mwk: imirkin: I have a GK208B too
04:05imirkin: mwk: ah ok. it has ? ? ? in the chip parameters fields
04:06imirkin: 128X+ 0e0f 0x106 GK208B ? ? ? ? ? ? ? \- ? ? ? 3 ? 3 ???
04:06mwk: seems I never got around to that
04:06imirkin: and i have a GK20A i can read stuff out from as well
04:07mwk: the main part would be dumping the 22400 range, then
04:07imirkin: give me the commands you want me to run :)
04:07mwk: nvapeek 22400 400
04:09imirkin: mwk: https://hastebin.com/uselukinex.erl
04:09mwk: the PMC ID is interesting already
04:09mwk: any clue on what fab they used to make this thing?
04:10imirkin: it came out of a dell
04:10mwk: I mean a chip fab like TSMC
04:10imirkin: i know what you mean :)
04:10imirkin: you now have all the information i have about its origins though
04:11mwk: anyhow, identical to GK208
04:11mwk: no surprises here
04:11imirkin: let me boot up the GK20A
04:12mwk: there are a few more params that could be checked, but they're very unlikely to differ from GK208
04:16imirkin: let's see... how do i do this on the tk1...
04:19nyef`: imirkin: I'm not sure why "subpack", it hails from the rnndb files and the Linux 3.7 nouveau code. It's some seven-octets-in-two-words structure, so it's basically high and low chunks of a 48-bit word... Sortof like the microinstruction word of a TI Explorer, now that I'm thinking about it.
04:19imirkin: nyef`: yes, i'm sure that was the inspiration :p
04:20nyef`: I'm sure it wasn't, but I couldn't help but notice the similarity. d-:
04:20skeggsb: subpack is what nvidia call the registers
04:20skeggsb: but, i'd also vote for a u8 array, and let nvkm assemble it
04:21imirkin: mwk: for GK20A: https://hastebin.com/wibuyavida.erl
04:21imirkin: [note to self: don't try to run nva* when the gpu is powered off.]
04:23imirkin: mwk: let me know if you need anything else - i have it running
04:24nyef`: skeggsb: If nvkm is to assemble it, where does the code go?
04:24skeggsb: nyef`: the place that writes the registers?
04:24imirkin: nyef`: maybe a helper in hdmi.c or whatever
04:25imirkin: or yeah, just do it directly
04:25nyef`: skeggsb: All four nvkm/engine/disp/hdmi*.c files?
04:25mwk: imirkin: peek 104650, 105650, 106650?
04:25mwk: hm, probably need to poke ffffffff to 200 first
04:26mwk: also, SUBPs.... let me see how to find that
04:26imirkin: mwk: https://hastebin.com/ululilikuz.nginx
04:26skeggsb: nyef`: yep, it's not like you're doing anything horribly complex that needs a helper.. you're replacing a wr32(addr, subpack) with wr32(addr, infoframe << blah | infoframe]1
04:26skeggsb: but, you get the idea
04:27imirkin: mwk: writing fff to 200 first doesn't help for 104650/105650
04:27nyef`: Yeah, I get the idea... though there's a bounds-check to complicate things. Still doable, though.
04:27mwk: fair enough
04:27imirkin: i.e. they still return badf1100 and nouveau prints a mmio read fault error
04:28imirkin: 106650 = 3 though
04:28mwk: nvapeek 40000, 42000, 44000?
04:28skeggsb: i'm pretty sure gk20a only has "GR_COPY"
04:28skeggsb: none of the async ones
04:28imirkin: mwk: 40000 = 0, the other 2 get a "TIMEOUT" mmio read fault
04:28mwk: yeah, thought so too
04:28imirkin: (as opposed to the more usual IBUS mmio read fault)
04:30mwk: nvapeek 1408dc?
04:30imirkin: 001408dc: 121d000e
04:31mwk: hmm, but not unheard of
04:31mwk: apparently GF119 also has only one SUBP in total
04:32imirkin: well, this thing isn't exactly meant to be a powerhouse...
04:32mwk: the only thing left on my checklist is PPCs/GPC
04:32mwk: I can't imagine it being anything other than 1
04:34imirkin: let me know what i need to read out in order to check that
04:34mwk: but oh well
04:34mwk: nvapeek 503000 ; nvapeek 503200
04:34imirkin: 00503000: 00000007
04:34imirkin: the other one returns a IBUS mmio fault
04:34mwk: ... and the other one should go boom
04:34mwk: that completes my checklist
04:35mwk: though I'm curious what happens if you read 88000 range
04:35imirkin: 88000 = IBUS error
04:35mwk: who'd have guessed.
04:37imirkin: nyef`: btw, silly question, but you've verified that both GT215 and GK104 audio work fine, right?
04:37imirkin: [after your changes]
04:39nyef`: imirkin: Yes, I did. Had to change the gt215 code to make it still work, actually.
04:40imirkin: nyef`: ok cool
04:40nyef`: The 0x10000 bit in the vendor/generic infoframe control is important in that respect on gt215.
04:42imirkin: we didn't write it before...
04:42imirkin: oh - you added logic to turn it off.
04:42nyef`: You never enabled the infoframe before, either.
04:42imirkin: yeah... so why'd it work? :)
04:45nyef`: Either the defaults are correct, or you need to enable the infoframe before flipping that bit breaks audio.
04:50skeggsb: that bit probably means "this generic infoframe is the audio infoframe" - and - if both that and the audio infoframe are enabled, shit gets hectic
05:04imirkin: nyef`: why do you have *=2 the clock for frame packing -- does the dot clock not take the fact that there are twice as many frames into account?
05:06nyef`: imirkin: Not according to the i915 driver.
05:06nyef`: Not that I really know, none of my panels appear to do frame packing.
05:06imirkin: ok, and you don't have a display that actually supports it to see what an edid looks like
05:09nyef`: Right. My displays basically just support sbsh and tb modes.
05:39imirkin: nyef`: wait, so on gt215 you flip the bits on, and gk104 you flip them off?
05:40imirkin: (i mean 0x10000 for the vendor infoframe control reg)
05:41nyef`: On one, it breaks audio not to. On the other, it just doesn't *work* if you do... but doesn't affect audio either way.
05:44nyef`: So, the gt215 "feels like" a variant of the g84, while the gk104 feels very different.
05:46imirkin: gt215 has the HDA device though, while g84 does not
05:47imirkin: [you have to hook up to a header on the video card directly, and there a ton of not-really-re'd registers that control the sampling/etc parameters]
05:48nyef`: Which suggests that the gt215 was more "let's get HDA working with this" and less "we've got the opportunity to re-do all of the quirky bits that don't really fit, and plan for future expansion".
05:51nyef`: ... Is it at least a reasonably-standard header?
05:53imirkin: the S/PDIF header?
05:53imirkin: most sound cards can output it, so you just hook up the wires.
05:54nyef`: Ah, okay. I was afraid that it'd be something funky that you need to obtain a special adaptor for or something.
05:56imirkin: no. just a way of delivering the audio to the video card
08:41michele: imirkin_: it was written before the irc discussion
11:10maedhbh: hi, i have a GeForce GTX 960 (Maxwell family), i saw this card in the supported card on nouveau.freedesktop.org, does it really work?
11:10maedhbh: (i tried few months ago but it didn't)
11:11maedhbh: some options on the matrix features page are marked on WIP/TO DO
11:49pmoreau: maedhbh: It should work fine, though you won't get any reclocking.
12:08maedhbh: @pmoreau, you can have reclocking without doing anything? 'cause i don't know what is that X)
12:13pmoreau: maedhbh: The memory and shader cores can run at different frequencies, depending if you have a lot of stuff to do, or if you would rather save some battery life.
12:14maedhbh: @pmoreau, so it can happened at every time?
12:14pmoreau: By default on those cards, the frequencies are at the minimum, so without changing those frequencies, your GPU will be less powerful than an Intel integrated GPU.
12:15pmoreau: It can happen at any time, but currently with Nouveau, it will never happen
12:15pmoreau: (For the 9xx and 10xx series)
12:16maedhbh: okay, and if i get unlucky and that happens. Can i hope that there is an option in my BIOS to keep the same frequency everytime?
12:17pmoreau: If you are using Nouveau, it **won’t** happen, even if you are unlucky
12:17pmoreau: Plus, even if reclocking was supported on those cards, you have to change the frequency manually
12:17maedhbh: okay, i'll try this week-end then
12:18maedhbh: @pmoreau, thanks for your answers : )
12:18pmoreau: No problem
14:22RSpliet: mwk: for future reference, could you archive https://www.micron.com/~/media/documents/products/data-sheet/dram/ddr4/4gb_ddr4_sdram.pdf in the ram subdir on your webstorage please?
15:16mwk: RSpliet: done
18:21nyef`: Hrm. Okay, upon re-checking the spec, I can believe that the "mandatory" modes are indicated by that one bit in the EDID, and that said bit is set for both of my 3D panels... But not that the implementation in the kernel is necessarily correct.
18:22imirkin_: nyef`: yeah, i dunno. it seems like it actually adds too few modes
18:22imirkin_: but in practice it works out
18:22imirkin_: nyef`: coz it should be adding the 24hz modes no matter what
18:22imirkin_: but it's only adding them if there are already the relevant 2d modes
18:24nyef`: My reading of the spec says that if the EDID advertises only a 512x384x1bppx60Hz mode (a classic "compact" Mac CRT spec), but has the 3D bit set, it must also support the 24Hz and 60Hz 3D modes.
18:24imirkin_: [that is also my reading]
18:24nyef`: Which isn't what the kernel logic is doing.
18:24imirkin_: but the kernel logic is more conservative than it ought to be
18:25nyef`: Yet my hardware has the bit set, but doesn't like some of these modes.
18:25imirkin_: or you're not setting them correctly
18:25imirkin_: (crazier things have been known to happen)
18:26nyef`: Right. Either there's more to figure out with nouveau and 3D, or there's more to figure out with E-EDID and 3D in practice.
18:26imirkin_: both seem likely ;)
18:26imirkin_: tbh i'm surprised that your hw doesn't support any of the frame-packing modes
18:27imirkin_: but did you also have trouble with e.g. 1920x1080@24 top-and-bottom (where side-by-side is claimed to be supported)
18:29nyef`: Only had trouble with frame-packing modes.
18:29imirkin_: nyef`: ok, so ... the 1920x1080@24 top-and-bottom isn't advertised in your edid
18:29imirkin_: so my guess is that the issue is with how you're sending the frame packing modes
18:32nyef`: Yeah, either I'm sending FP modes wrong, or there's something that in practice overrides the FP mode support indicated by the EDID.
18:33nyef`: Substantial lack of visibility into what's actually being sent on the wire doesn't help.
18:33imirkin_: your DMM doesn't help? :)
18:34nyef`: Hell, give me a week and I'll have access to a 200MHz o-scope!
18:34nyef`: (Might be a 300MHz scope, I forget.)
18:37nyef`: http://paste.lisp.org/display/335893#1 for the EDID for the other display, btw.
18:38imirkin_: supports_ai? must be a smart tv!
18:39nyef`: For all I know, it might be.
18:40imirkin_: did the LG tv also work with top-and-bottom
18:40imirkin_: or only side-by-side?
18:40nyef`: Again, only the FP modes seemed to fail.
18:41imirkin_: ok. that's useful info.
18:42nyef`: For that one, though, I have to wonder if the 3D_Structure_ALL part of the EDID is supposed to override the "mandatory" mode list.
18:45nyef`: I can see it claiming SBSH and TB for the 1920x1080@24 and 1280x720@60 modes via 3D_Structure_ALL and 3D_MASK.
18:49nyef`: So, two possibilities: One, neither display actually supports FP modes. Two, nouveau isn't generating FP modes correctly.
18:52nyef`: To rule out possibility one, get a known-good driver (and possibly video card), cause it to generate an FP signal, route it to the display, and see if it works. To rule out possibility two, find a known-good display that accepts FP modes, and route an FP signal to it OR rule out possibility one using the windows nvidia driver.
18:53nyef`: (Actually, that last case would rule IN possibility two.)
18:54imirkin_: nyef`: do you have access to intel hw where this is supported? guessing hsw+ or maybe ivb as wel
18:54nyef`: Known-good hardware + Linux drivers... i915 with HDMI?
18:55imirkin_: well, i915-which-supports-3d + hdmi
18:55imirkin_: you need hdmi 1.4 or whatever
18:55imirkin_: dunno what the limit is. i bet #intel-gfx can tell you.
18:57nyef`: I will have access to unknown video hardware with an HDMI output (running windows) in a few days. If that's not suitable for 3D, then I'd need to buy something.
18:57imirkin_: hrmph, that's not idea.
18:58nyef`: On the other hand, in a few days I'll have access to the windows restore disks for this hardware.
19:00imirkin_: i assume nvidia blob driver has no support for these things?
19:02nyef`: Not that I've seen, though I suppose it _might_.
19:14mwk: alright, this is starting to look halfway reasonable
19:41airlied: skeggsb: yo, ever see anything on an external vblank sync across multiple nvidia gpus
19:42imirkin_: airlied: are you talking about frame-locking for multiple CRTC's?
19:42airlied: imirkin_: across multiple gpus
19:42imirkin_: that's crazy-talk!
19:42airlied: apparantly some quadros can do it
19:43airlied: via possibly the sli connector
19:43imirkin_: 64 = SLI Raster Sync A: This signal is carried across the SLI bus to synchronize the RG between GPUs. This signal will always be set as Alternate.
19:44airlied: that might be part of it alright
19:44imirkin_: probably a different thing though...
19:45airlied: these ppl used it in a serious flight sim
19:45airlied: ah quadro sync
19:46airlied: BNC genlock connector
19:46imirkin_: 63 = ExtSync0 - Used with external framelock with GSYNC products. It also could be used for raster lock.
19:46airlied: ah that is it
19:46imirkin_: RM is responsible for discerning Raster Sync or Flip Lock from the GPIO Function.
19:47imirkin_: it's one of the bits in the GPIO tables
19:50imirkin_: airlied: there are also LockPin's which interact with it
19:50imirkin_: look up the dcb spec i linked to
19:50imirkin_: and search for "lock pins"
19:50imirkin_: and the stuff before that diagram
19:54glennk: airlied, some interesting use case for that pin?
19:54airlied: just talking to some ppl using it with nvidia at conference
19:54airlied: wondered if nouveau could do it
19:55airlied:can't afford flight simulator
19:55airlied: I don't think AMD have anything similiar either
19:55imirkin_: def not out of the box, but with the proper hardware in-hand, it shouldn't be too difficult
19:55glennk: i think amd had some fire* card with genlock on it at some point
19:56airlied: ah yes some s400 sync module
19:58imirkin_: 66 = Swap Ready In A: This signal, which is related to Fliplocking, is used to sense the state of the FET drain, which is pulled high and is connected to the Swap Ready pin on the Distributed Rendering connector.
19:58imirkin_: 67 = Swap Ready Out: This signal, which is related to Fliplocking, is used to drive the gate of an external FET.
19:59imirkin_: [these are all gpio's]
19:59glennk: so basically pull low for sufficient time to trigger flips on slave cards
20:04mupuf: imirkin_: nvidia's framebuffer lock required an external BNC connector, last I checked
20:05mupuf: but what you found may also allow this, quite likely, but not sure how they would synchronize the vblank
20:06mupuf: maybe it is software that streches vblanks or shortens them to synchronize multiple monitors
20:13mwk: mupuf: the SLI connector also includes vsync signals
20:18mupuf: mwk: pretty nice!
20:31nyef`: ... I wonder if my test laptop will boot with a usable display if I pull the discrete card?
20:31nyef`: I'm not sure that I'm going to try it, but it would be interesting to know.
20:35nyef`: If it *does* boot that way, it'd almost certainly be an intel GPU.
20:44imirkin_: coz it
20:44imirkin_: coz it'd be odd for an intel cpu to have come bundled with an amd apu? :)
20:46nyef`: Something like that, yes.
20:46nyef`: Though you can get this hardware with an AMD card in the MXM slot.
20:49nyef`: Found a comment on an earlier hardware rev that "Since it has the 120Hz screen, it needs to have a GPU too [sic] boot up, otherwise you will get 8 beeps."
20:50nyef`: So, I swap out the eDP panel for the LVDS panel, pop the MXM card, and I should have an intel GPU... Maybe.
20:51imirkin_: sounds ... easy
20:52nyef`: Exactly! And I need to get an mmiotrace of the blob on the LVDS at some point anyway.
20:54nyef`: And it'll be good practice for later. My main system has the better chassis, but the test system has the better CPU.
21:17mwk: seems NV1 rasterizer gets hopelessly confused if vertices are submitted with wrong clip status
21:17mwk: I'm pretty sure that's not what two triangles should look like
21:23mupuf: mwk: I thought NV1 could only render quad?
21:23mupuf: oh, you can submit twice the same coordinates
21:24mwk: mupuf: no, quads are the only thing supported for texturing
21:24mupuf: ah ah, ok
21:24mwk: solid rectangles are supported natively
21:24mwk: err, triangles
21:24mwk: that's what NV1 can do :)
21:25nyef`: A triangle is "just" a rectangle in which three of the points are colinear, right? (-:
21:25mwk: the pretty interpolated quads are drawn by decomposing them to straight-edged texel quads, which are decomposed into triangles, which the rasterizer supports natively
21:26mwk: nyef`: a quad, not a rectangle
21:26mwk: and... it is, if it's solid. if it involves texturing, it's not :)
21:26nyef`: Yes, a quad, sorry.
21:26imirkin_: very few rectangles have 3 colinear points...
21:27mwk: which is why NV1 had no hope of ever supporting D3D
21:27kuzetsa: I don't think it's normal for video playback using a driver/firmware (extracted blob) or whatever which in this case happens to be nouveau... it shouldn't lock up my xserver and/or crash my computer, I think
21:27imirkin_: kuzetsa: yes, that's a nice thought.
21:28mupuf: mwk: your work should go to a museum, seriously!
21:28kuzetsa: keyboard stops responding, including "numlock / capslock" buttons to check to make sure it's responding to input (since that gets processed by the OS/kernel/drivers or whatever) ... but the mouse cursor still moves normally on the screen even though the video is frozen
21:28nyef`: ... Three colinear right-angles in the same quad... probably requires a rather interesting spatial structure.
21:28kuzetsa: imirkin: well I never had this issue on the nvidia-blob-style driver :(
21:29imirkin_: kuzetsa: if you're looking for stability, use the blob
21:29imirkin_: or amd
21:29imirkin_: or intel
21:29nyef`: ... or a beach ball in a hurricane? (-:
21:30imirkin_: it's an unfortunate situation, but it is what it is.
21:30imirkin_: patches welcome.
21:31kuzetsa: I guess I really was in denial about how bad the situation is WRT nVidia "black box" / undocumented stuffs + difficulty reverse engineering the relevant things to attempt to produce the nouveau drivers :/
21:31imirkin_: our approach is generally "try to not do things that hang the card"
21:31imirkin_: or at least ... my approach
21:31kuzetsa: I've gone from thinking "maybe it's not so bad - if it's usable enough that I won't suffer, I might even help out if I have the time"
21:32imirkin_: what video player were you using btw?
21:32kuzetsa: well I went from that --> considering a sort of dual-stack / switchable driver setup where I might unload one driver or the other and switch to the one I'm using for stability / dev stuff
21:32skeggsb: kuzetsa: another good idea is, check dmesg, and let me know if there's more info there from nouveau during the hang - i might be able to help make us recover better too
21:33kuzetsa: skeggsb: sure why not... I haven't tried to play any videos or other risky things in a few hours, so I'll have to either grep or guess when the last crash was
21:33orbea:wonders if this is mpv again
21:33kuzetsa: IDK how to do "switch drivers without rebooting"
21:33imirkin_: skeggsb: try mpv with opengl video output + vdpau hwdec. that's a very simple way to get multithreading to gum up the works and hang things.
21:33kuzetsa: on windows, vlc is the most stable player I ever used for this particular gpu/laptop
21:34orbea: last time I tried that it was instant crash... :P
21:34imirkin_: kuzetsa: fyi, i use mplayer - never had problems.
21:34imirkin_: (not to be confused with mpv or mplayer2 or any number of forks of the mplayer project)
21:34kuzetsa: imirkin: do you have optimus-type hardware?
21:34skeggsb: imirkin_: the mt stuff effects vdec too?
21:35imirkin_: skeggsb: well, it does opengl in one thread and vdpau in another thread
21:35skeggsb: yeah, but there's like, zero shared state between the two
21:35imirkin_: skeggsb: NV_vdpau_interop
21:35kuzetsa: optimus is why it took me years to finally fix up (clean install, actually) a gentoo install -- my windows dualboot finally died from bitrot, but for stability-reasons it was the daily-use OS for a very long time for me
21:35skeggsb: yes, right
21:35imirkin_: skeggsb: and there's a shared screen
21:35imirkin_: (i mean pipe_screen)
21:35kuzetsa: ok, poking dmesg
21:35skeggsb: well, i should perhaps not ignore vdec completely in my mt branch then :P
21:36kuzetsa: well that's annoying
21:36skeggsb: i'll have to double-check, but i don't think much from the screen is shared - the vdec stuff uses its own channels and everything
21:36kuzetsa: $ wc -l dmesg
21:36skeggsb: but, admittedly, i didn't look in too much detail
21:36imirkin_: skeggsb: yeah .... you're probably right
21:36kuzetsa: 722 lines, and it's all from after the reboot after the lockup/crash
21:36kuzetsa: so there's no useful info in dmesg
21:36imirkin_: skeggsb: that said, SOMETHING is shared, since it dies hard
21:37imirkin_: skeggsb: probably the genero transfer stuff, etc
21:37skeggsb: yeah, and, well, they can share buffers too
21:37skeggsb: sooo, ok, that's enough motivation to not ignore it
21:41Tomin: mwk: I guess that "Intruduction" is a typo (on that envytools readthedocs page)
21:44nyef`: "M-x flyspell-mode" time?
21:44nyef`: Heh. Nice commit message. (-:
21:45nyef`: (I'm going to presume that it was intentional.)
21:45Tomin: it's alright, happens to everyone
21:45mwk: nyef`: it's the law of typo conservation, typos cannot be destroyed
21:45mwk: you have to move them somewhere harmless, like the commit log
21:46nyef`: I'll have to remember that one.