01:24 mlankhorst: ty :p
01:25 mlankhorst: when did you get ops?
07:44 imirkin: for anyone waiting on blobless maxwell (gm107, not gm204) support, check out http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=97c288c10
07:51 buhman:waits for blobless gk106
07:51 imirkin: :p
07:52 imirkin: doesn't your board just not work, blob or not?
07:52 buhman: blob works fine
07:52 buhman: I submitted mmiotraces a long time ago
07:52 imirkin: you have the HUB_INIT timeout thing no?
07:52 buhman: yep
07:52 buhman: https://bugs.freedesktop.org/show_bug.cgi?id=80627
07:53 buhman: ^ that symptom vanished a few kernels ago, then it came back
07:53 imirkin: and it's marked as a duplicate of 70354
07:53 imirkin: which i reworded to be " [NVE6,NVE7] HUB_INIT timeout on graph init, blob fw doesn't help"
07:53 buhman: erm
07:53 buhman: I feel like 'blob fw' isn't the same thing as 'nvidia.ko'
07:54 imirkin: oh
07:54 imirkin: by blob you mean "nvidia's driver works"
07:54 imirkin: yes
07:54 buhman: erm, what else should work
07:54 imirkin: the maxwell thing was in reference to the blob's ctxsw fw
07:54 imirkin: i assumed you were talking about the same thing
07:54 buhman: oh
07:54 imirkin: quite foolish of me :p
07:55 buhman: so erm, should I be doing something different with nouveau other than just loading it?
07:55 imirkin: no... unless you want to use blob fw
07:56 buhman: erm how do I do that?
07:56 imirkin: which has been demonstrated to not help for your issue
07:56 imirkin: you extract it using e.g. my extract_firmware.py script
07:56 buhman: then load it how?
07:56 imirkin: and then you load nouveau with nouveau.config=NvGrUseFW=1
07:56 buhman: is this documented?
07:56 imirkin: there are words that say all of this
07:57 imirkin: i dunno if i'd call it 'documented'
07:57 buhman: I mean, I suppose the blob needs to go somewhere where nouveau can find it
07:57 imirkin: yes... /lib/firmware/nouveau
07:59 imirkin: buhman: follow these instructions http://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware
07:59 buhman: :D
07:59 imirkin: but like i said... this didn't help other people with this issue
08:00 buhman: I'm hoping it might at least have slightly different behavior ;p
08:00 buhman: also I haven't heard anyone else talking about what I fail to describe in https://bugs.freedesktop.org/show_bug.cgi?id=80627
08:02 buhman: imirkin: I've heard a variant of my motherboard that has a gk107 instead of a gk106 works completely fine
08:03 imirkin: it has to do with what's in the bios/vbios
08:03 imirkin: the card ends up getting super-mega-turned off, and apparently we can't turn it on quite right
08:04 buhman: can we make nvidia.ko turn it on for us then swap it out with nouveau?
08:04 buhman: ;p
08:04 imirkin: sure... although not if you plan to run displays
08:04 buhman: O.o
08:05 imirkin: the blob started doing something that messes them up *hard*, and we can't get them to update
08:05 buhman: 'update'?
08:05 imirkin: the framebuffer being scanned out
08:07 buhman: http://cgit.freedesktop.org/~darktama/nouveau/tree/drm/nouveau/nvkm/engine/gr/fuc/gpcgf100.fuc3.h?id=97c288c10334dfd0672e3c24d44955770352db0e#n39 this looks like magic
08:19 imirkin: it's compiled from the .fuc files
08:20 imirkin: forcing the kernel to depend on the fuc assembler seemed a little crazy, so we check in the compiled artifacts as well
08:25 glennk: the usual custom with generated files is to have a comment how they got generated at the top...
08:27 imirkin: there's a makefile...
08:27 imirkin: i thought
08:29 imirkin: hm weird, appears to be gone
08:29 imirkin: skeggsb: maybe just stick a Makefile into the relevant dirs which calls envyas?
08:30 imirkin: i'm guessing it got dropped as part of the Kbuild transition
10:53 davidrlunu: Hello everyone. Is GK107 nouveau driver having good control on the fan speed of GPUs ( GT 740 in my case ) ?
10:54 imirkin_: there have been a bunch of reports where it seems like nouveau is unable to control the fan
10:54 imirkin_: but in general it should be fine
11:37 mlankhorst: it's a pl2303, phew
11:53 tobijk: mlankhorst: yay :)
11:53 mlankhorst: now I need a null modem cable, forgot to check that part :p
11:53 imirkin_: see... so much easier to just not bother :p
11:54 tobijk: dont you have parts to build one on your own? i had to build rs232->stereo plug ^^
11:54 mlankhorst: I lack the drive to build my own
11:55 mlankhorst: at some point I want it to just work(TM)
11:55 imirkin_: that's why i shut mine off, put it on the shelf, and went back to playing with the a3xx board
11:55 imirkin_: s/why/when
12:00 mlankhorst: serial port is always useful
13:02 pmoreau: Will there be some Nouveau pull request for 4.0? skeggsb doesn't seem to have created a 4.0 branch yet on his repo
13:02 imirkin_: i'm guessing he'll be up soon and be able to answer that himself. i would assume there will be, since a few things have been fxied
13:02 imirkin_: fixed*
13:03 pmoreau: :)
13:03 pmoreau: I just saw some pushbuf fixes for nv50/disp on he's repo
13:04 pmoreau:hopes it fixes his G96 issues O:-)
13:04 imirkin_: test it out...
13:04 pmoreau: Yep, going to try that out immediately!
13:20 pmoreau: Still need to fix EVO going wrong, too bad :D
13:40 davidrlunu: Hey just wanted to confirm that GL107 nouveau work AWESOMELY and completely speed down the gpu fan at a normal speed :D
13:41 imirkin_: that's nouveau's primary function in fact -- slowing down fans :)
13:42 davidrlunu: i was so dissapointed by the fact that the gpu fan was a bit too loud even for a PC ...but after installing the drivers, as soon as i booted and entered into the framebuffer mode the fan slowed down A LOT ...it almost got me a mini heart attack XD
13:43 imirkin_: davidrlunu: you should be able to monitor things in 'sensors'
13:43 imirkin_: depending on your gpu specifics you should see temp and potentially rpm of the fan
13:43 imirkin_: by default nouveau will use various vbios settings for determining the speed at which to spin the fan, but if you don't like it you can also control the fan manually
13:44 davidrlunu: imirkin: yeah sensors it's seeing something but as acpiz interfaces, i still need to configure my kernel ( fresh gentoo install )
13:44 davidrlunu: imirkin:that sounds even more awesome :D
13:45 imirkin_: davidrlunu: e.g. something like http://hastebin.com/raw/lejofenobo
13:45 imirkin_: (in sensors output)
13:45 imirkin_: if you don't see that, you might have forgotten to enable some option
13:46 davidrlunu: You people are doing an amazing job! I only betrayed you once ( intalling the blob ) due to the fact that i was using a lap top and the nouveau drivers were not controlling the temperature of the gpu, so it was somehow (10-15°C) overheating
13:46 imirkin_: use whatever works best for you :) do note that if you boot with nouveau.pstate=1 you should be able to reclock your GK107
13:47 imirkin_: it's completely manual though, and some levels may lead to crashes, so use with caution
13:47 davidrlunu: imirkin: i see the sensors and ... 22°C out of 95°C :D
13:48 imirkin_: uhm
13:48 imirkin_: is it freezing cold?
13:48 imirkin_: 22C inside a computer case is fairly impressively low
13:48 davidrlunu: imirkin:i have 5 fans
13:48 imirkin_: that means that ambient temp is probably below 20C
13:48 tobijk: *brrrr*
13:49 imirkin_: which, while not _cold_ is definitely colder than usual
13:49 davidrlunu: 24°C in my flat according to the thermal sensor ^^
13:49 imirkin_: hmmm... i guess someone's lying
13:49 davidrlunu: anyway as ive saying i have 5 12cm fans inside
13:49 tobijk: do you create a storm inside there? :D
13:49 imirkin_: fans don't reduce the temperature of the air in your room
13:49 davidrlunu: LOL
13:50 imirkin_: they merely help equalize temperature
13:50 davidrlunu: then maybe are not 24°C in here :|
13:51 tobijk: those sensors tend to be not that exact, maybe one measures +1°C and the other -1°C and ther you go ~
13:51 imirkin_: or maybe the card sensor is being read wrong/calibrated wrong
13:51 davidrlunu: imirkin:well i guess is definetly not 20 °C inside here
13:51 davidrlunu: my cpu is 25° and the mobo is 15°C
13:51 davidrlunu: XDDD
13:53 tobijk: nice "energy harvesting" system you got there, picking energy from the air ;-)
13:53 davidrlunu: tobijk:what do u mean?
13:53 tobijk: just kidding
13:54 davidrlunu: :)
13:54 imirkin_: if the readings were correct
13:54 imirkin_: it'd mean that your machine is acting as an air conditioner
13:54 imirkin_: hwoever it's more likely that the readings are just plain wrong
13:54 imirkin_: or you're lying and are actually sitting inside a walk-in freezer
13:55 imirkin_: and it's 24F, not 24C :)
13:56 davidrlunu: imirkin:ok so right now i am compiling and everything is arround 29°C
13:56 davidrlunu: :|
13:56 imirkin_: try make -j8
13:56 tobijk: what surprises me is that all readings are wrong (cpu, mobo, gpu)
13:57 davidrlunu: imirkin:i am currently under -j5
13:57 imirkin_: what cpu do you have?
13:57 davidrlunu: lol, friend confirms that "is fuck*ng freezing in here"
13:58 davidrlunu: i guess this solves the misteries
13:58 davidrlunu: : {
13:58 davidrlunu: i have an i5 4460
13:58 tobijk: try -j8 :)
13:58 tobijk: at least
13:58 imirkin_: nah
13:59 imirkin_: quad core, no ht. -j5 makes sense.
13:59 tobijk: ht thingy :>
13:59 davidrlunu: yep no HT
14:00 tobijk: :o, i thought all of the nwer ones got it for quite a while now
14:00 davidrlunu: and btw, do you have any idea what -march to use? i went plain generic x86_64
14:00 imirkin_: corei7-avx2
14:00 imirkin_: er
14:00 imirkin_: core-avx2
14:01 davidrlunu: imirkin:i proposed the same thing on the gentoo chan and they were like "lol that -march would be good for a last century cpu" oO
14:01 imirkin_: the generic one?
14:01 davidrlunu: but in fact the gcc4.8 suggest the same for Haswell procs
14:01 davidrlunu: no for the core-avx2
14:01 imirkin_: core-avx2 is the correct one for your cpu
14:02 imirkin_: they were probably thinking of core2
14:02 imirkin_: which is a considerably older cpu
14:02 buhman: why not native?
14:02 davidrlunu: i will update my make.conf with the core-avx
14:02 imirkin_: core-avx2
14:02 imirkin_: buhman: some people like (e.g. me) like to be explicit
14:03 buhman: isn't native more explicit than core-avx2?
14:03 imirkin_: e.g. if someone sends me something with -march=native, i have _no_ clue what "native" is for them
14:03 davidrlunu: buhman:as far as i've learned on modern cpus "native" and gcc 4.8 are is having some issues
14:03 imirkin_: but if they specify an exact arch, i know exactly what they built
14:03 buhman: that sounds like a bug
14:03 buhman: if that's actually the case
14:05 davidrlunu: my experience on the irc chans is that many people have many opinions but is always wise to pounder the other's opinions and follow the one that more make sense, based also on the knoledge you gather with the study of the issue you are working on
14:06 davidrlunu: this is how after a very...very long debate on the gentoo chan, i decided that i have to align my SSD in 6144 sectorrs...against any kind of standard
14:06 imirkin_: -march=native is easy to put into guides, but it hinders debugging later on, so i avoid it.
14:08 tobijk: i wouldnt go with any special -march if you intend to debug ...
14:09 davidrlunu: imirkin: i will go with -march=core2-avx :)
14:09 imirkin_: davidrlunu: preferably core-avx2
14:09 davidrlunu: imirkin:+1
14:09 imirkin_: since that one's actually a thing :)
14:09 davidrlunu: ^^
14:15 buhman: -march=avx-core2
14:15 buhman: -avx=march2-core
15:40 milkywayland: hi,is the displayport dvi and vga registers also mapped to pci bar of some kind?
16:00 milkywayland: can't imagine they'd be mapped to somewhere else but have not found the code saying that
16:18 milkywayland: neither docs i assume they are in bar's so called pci configuration space, bios or os moves them there
16:32 milkywayland: base address registers , ah stupid pointless channel
16:32 milkywayland: scratcvh your nuts mofos
18:19 davidrlunu: Hello (again) everyone! Ehm i am getting some really strange behaviour with the white color in X. If i open urxvt (which is completely white) in full screen, i can see the monitor vacillating
18:20 imirkin: is it hooked up by VGA?
18:20 davidrlunu: I have a GT 740 ( GK 107 )
18:20 davidrlunu: yes
18:20 imirkin: can you use a digital connector?
18:20 imirkin: like DVI or HDMI?
18:21 davidrlunu: i think i have an adapter somewhere
18:21 imirkin: adapter won't help
18:21 davidrlunu: oh then no :/
18:21 davidrlunu: i don't have a DVI cable
18:21 imirkin: if it's an analog input on the monitor
18:22 davidrlunu: imirkin:but it has nothing to do with the refresh rate?
18:22 imirkin: well, if it's a long cable, or it doesn't have ferrite thingies on it, or it's an old monitor, then it'll look like crap
18:22 imirkin: oh, it might be the refresh rate... do
18:22 imirkin: xrandr --output VGA-1 --prop 'scaling mode' 'None'
18:22 davidrlunu: omw
18:24 davidrlunu: imirkin:unrecognized option 'scaling mode'
18:25 imirkin: uhm
18:25 imirkin: pastebin the output of 'xrandr --prop'
18:27 davidrlunu: http://sprunge.us/UaTV
18:29 imirkin: well, it's set to none in any case, so i guess it doesn't matter
18:29 imirkin: 1920x1080 requires a very good VGA cable, and even then, you can end up with a bunch of noise
18:30 davidrlunu: imirkin:the fact is that i had the same monitor connected to the lap-top and it had no such noise :S
18:31 imirkin: with the same cable?
18:31 imirkin: and also 1920x1080?
18:31 davidrlunu: imirkin: yes sir
18:31 imirkin: hrmph
18:31 davidrlunu: imirkin:yes
18:31 davidrlunu: imirkin:had both the lappy and the 1920 monitor together on
18:31 imirkin: dunno.
18:32 imirkin: could be that we're configuring the VGA outputs somehow incorrectly on the later cards... VGA doesn't get tested a lot
18:32 imirkin: or it could be that the electronics on that card are crap
18:33 davidrlunu: imirkin: i took a closer look behind the case and.... i think the VGA cable is somehow touching a side of the case, right at the input into the GPU
18:33 imirkin: it's probably one of those half-height cards with the VGA connector fed off of a ribbon... not exactly a recipe for high-frequency success
18:33 davidrlunu: could this be relevant?
18:34 glennk: should be easily tested by trying a lower resolution and seeing if the same artifacts appear
18:34 davidrlunu: glennk:right, i try imediately
18:34 imirkin: that would probably improve things since it'd ground the shielding :)
18:36 glennk: unsure what would actually happen with such a ground plane at >120Mhz signalling :-/
18:36 imirkin: hehe
18:37 imirkin: yeah, my knowledge of signals ends at around 5MHz
18:37 imirkin: after that it breaks
18:43 davidrlunu: imirkin:ok i finished testing and the only noise clear resolution + refresh rate is 1680x1050 at 59.95 MHz
18:44 davidrlunu: all the others have the same noise...the lower the resolution the bigger the noise
18:44 imirkin: heh weird
18:47 davidrlunu: imirkin:i guess it's time for an HDMI cable ^^
18:48 glennk: could try to up the refresh rate if the noise is in a particular frequency band
18:49 glennk: but if its an lcd panel and not a crt, yeah, use a digital interface :-)
18:49 davidrlunu: glennk:yes it's a LED monitor
18:52 davidrlunu: Btw, i am on gentoo, could this be relevant? I mean the only thing i did was to disable framebuffer and dri support and only set nouveau drm
19:07 davidrlunu: imirkin:lol i did some super crazy "1337 skillz h4cks" to my monitor settings ( the physical ones ) and the disturbance is gone :)
19:08 imirkin: excellent
19:12 davidrlunu: imirkin:btw, about that temperatures earlier, you were right, something was not right! After enabling I2C sensors support in the kernel and rebooted... the sensors started to show REAL temperatures
19:13 imirkin: cool
19:15 davidrlunu: Thank you again for the time and support kind people! I wish you all a good day or a good night :)
22:28 imirkin: gnurou: i don't think Deepak really understood what i was saying... are you guys working together on this?
22:34 gnurou: imirkin: sorry about this. Yes, we are (or rather, we will :))
22:34 imirkin: [or maybe i'm the one not getting it]
22:35 imirkin: all i know is that it was a 3K line patch and it should be fewer lines per patch :)
22:35 gnurou: let me take care of the first few rounds of reviews, Deepak is new to upstreaming and might need some guidance
22:35 imirkin: sounds good
22:36 gnurou: drawing more people in means more contributions, but it also means we need to guide them a bit - should have done this internally maybe
22:36 imirkin: nah it's fine
22:37 imirkin: gnurou: totally unrelated -- how do i tell that i've successfully booted the tk1 into recovery mode? is it based on what i see in usb?
22:37 gnurou: lsusb should report a device saying "Nvidia corp."
22:37 imirkin: k
22:37 gnurou: if you have it, it should be able to take commands through tegrarcm
22:38 gnurou: still don't want to use that rootfs I crafted with love? :)
22:38 imirkin: awesome. gonna give your boot script a shot
22:38 imirkin: well... i have my own rootfs which i crafted...
22:38 gnurou: with love?
22:38 imirkin: can't say it was with love, but it works and has the environment i like
22:39 gnurou: fair enough
22:39 imirkin: i think my biggest point of dissent with the "established" way of doing things is i want to leave the emmc alone
22:39 gnurou: well you will at least need to write U-boot to it, but after that you are free to boot off a SD card
22:39 imirkin: do i?
22:40 imirkin: i thought with your method i could just boot over otg + nfsroot every time
22:40 gnurou: that is, unless you send U-boot through tegrarcm, and have it run from there
22:40 imirkin: right
22:40 imirkin: that was my plan
22:40 gnurou: but that would require you to do so for every boot
22:40 imirkin: exactly
22:40 imirkin: i don't really see a problem with that :)
22:41 gnurou: please do as you see fit then :)
22:41 imirkin: once i succeed in doing it once, a second time should be considerably easier
22:41 gnurou: yeah, it would be the same anyway
22:43 gnurou: I have personally written U-boot to eMMC, and have it look at the SD card first before checking the network
22:43 gnurou: works nicely with my workflow now that I am not hacking too low-level anymore
22:43 gnurou: and Nouveau as a module on the NFS root which I then can unload/reload at will
22:44 imirkin: yeah, i guess i might switch to that at one point
22:45 gnurou: anyway, let me know if you have any trouble, I know it can be hard to get right the first time
22:45 imirkin: will do... i need to press both buttons to get into recovery mode right?
22:46 gnurou: yes, recovery + reset
22:48 imirkin: and do i need to write something special to the boot.scr so that u-boot *doesn't* flash itself?
22:49 imirkin: (i have this odd recollection that it was the default)
22:49 gnurou: depends where this boot.scr comes from
22:49 imirkin: i'm using the boot-kernel thing you sent
22:49 gnurou: oh, then you should be fine
22:50 gnurou: U-boot will only flash itself if given a script that asks it to do so, which is what the tegra flasher does
22:50 imirkin: ah ok
22:50 gnurou: my script does not IIRC
22:50 imirkin: os.system('tegrarcm --bct ' + bct + ' --bootloader=' + outfile + ' --loadaddr=' + hex(loadaddr))
22:50 gnurou: yeah, that the tegrarcm command to load U-boot into RAM
22:51 gnurou: then U-boot will starts and will execute boot
22:51 gnurou: then U-boot will start and execute boot.scr
22:52 imirkin: and for argv[3] (zImage_dtb), do i use the u-boot.dtb file you had in there, or something else?
22:52 imirkin: oh, looks like something else
22:52 imirkin: tegra124-jetson-tk1.dtb probably
22:53 gnurou: from the name I'd say it is supposed to be the zImage with its DTB appended to it
22:54 imirkin: hm, well send success
22:54 imirkin: but boot fail
22:54 gnurou: probably because no DTB
22:54 imirkin: padder.cat(zImage)
22:54 imirkin: padder.pad(dtboffset)
22:54 imirkin: padder.cat(zImage_dtb)
22:54 imirkin: probably just the dtb itself
22:54 gnurou: ah sorry, that's the dtb only indeed
22:55 imirkin: let's say everything worked and i was using an upstream kernel, would hdmi work?
22:55 gnurou: yes
22:55 imirkin: is it a 100mbit phy or gbit?
22:56 gnurou: ethernet is gigabit IIRC
22:56 gnurou: yup, it is
22:56 imirkin: Ethernet: a RTL8111GS Realtek 10/100/1000Base-T Gigabit LAN
22:56 imirkin: indeed
22:56 gnurou: have you managed to boot?
22:56 imirkin: no
22:56 imirkin: but i'm doing _way_ better than last time
22:56 imirkin: tegrarcm worked
22:56 imirkin: that's like a 1000x improvement over before
22:56 gnurou: there might be some issue with the padding my script it using ; let me double-check
22:57 gnurou: https://gist.github.com/Gnurou/8414813
22:57 gnurou: is it what you are using?
22:57 imirkin: looks right
22:57 imirkin: http://hastebin.com/uholisagot.py
22:58 gnurou: lemme check
22:59 imirkin: i might have missed something in the zimage though
22:59 imirkin: i should probably check against your config options
22:59 imirkin: and... i should hook up the hdmi and see what's up. oh, except i don't have my hdmi cable here.
23:02 imirkin: fwiw this is from a ~upstream 3.19 kernel -- should that work?
23:03 gnurou: yes, you should at least have HDMI output
23:03 gnurou: I just tested my script and can confirm it works, albeit my version of U-boot may be older, let me try with the latest one...
23:04 gnurou: I suppose you can see the serial output from Jetson?
23:04 imirkin: i used the thing you sent
23:04 imirkin: i have no outputs from it other than ethernet atm
23:04 imirkin: and usb otg
23:04 imirkin: no null modem cable, so no usb. and hdmi cable is... not here atm, so no hdmi. but i will have hdmi later :)
23:05 gnurou: so for all we know your boot might very well have succeeded :)
23:05 imirkin: no, i didn't get netconsole logs
23:05 imirkin: and i couldn't ping it
23:06 imirkin: and it didn't mount nfsroot
23:06 gnurou: ah, right, I didn't see your kernel options
23:07 gnurou: can you post your zImage, tegra124-jetson-tk1.dtb, u-boot-nodtb-tegra.bin and u-boot.dtb somewhere I can fetch them?
23:07 imirkin: sure....
23:07 imirkin: i'm using the u-boot* that you sent me
23:08 imirkin: but i'll tar it all up
23:08 gnurou: yep
23:08 gnurou: oh and your bct too
23:10 gnurou: your script turns out to be identical to mine, so the problem is not there
23:11 imirkin: well... it's _your_ script :)
23:11 imirkin: [uploading now...]
23:12 gnurou: yeah it's kind of a shitty script, sorry about that
23:12 imirkin: seems to work fine
23:12 imirkin: better than 90% of the scripts out there ;)
23:14 imirkin: come to think of it, i haven't tested this particular kernel
23:14 imirkin: although it's a derivative of one that worked fine on the ifc6410
23:14 imirkin: i should probably check it out on there as well...
23:15 gnurou: thanks! giving it a look...
23:18 gnurou: oh, that's fascinating
23:18 gnurou: your workstation happens to be called athos?
23:19 imirkin: yes
23:19 gnurou: my Jetson is called porthos
23:19 imirkin: hehe
23:19 gnurou: and my laptop aramis :P
23:19 imirkin: my laptop is aramis as well :)
23:19 gnurou: m(__)m
23:20 imirkin: it's a pretty uncreative scheme tbh
23:20 gnurou: maybe ; but it's a scheme that reveals taste for good literature ;)
23:21 imirkin: yeah.... dunno about that. but i'll take it
23:21 imirkin: perhaps my next box will be 'richelieu'
23:21 gnurou: so anyway ; I can boot your kernel, but it then blocks early
23:21 gnurou: http://pastebin/m514a2d28
23:21 gnurou: I think that's when it tries to mount the rootfs
23:21 imirkin: This paste has been removed
23:22 imirkin: oh
23:22 imirkin: no .com
23:22 gnurou: ah never mind
23:22 imirkin: er no, that's not it
23:22 gnurou: wrong address
23:22 gnurou: firefox's auto-completion redirected me to the wrong site...
23:22 imirkin: does network come up?
23:23 gnurou: http://hastebin.com/tululisuji.xml
23:23 gnurou: there you go
23:23 gnurou: seems like network doesn't come up
23:24 gnurou: I have adapted your kernel parameters to my NFS root, so it should work
23:24 imirkin: [ 2.052910] netpoll: netconsole: eth0 doesn't exist, aborting
23:24 imirkin: oops :)
23:24 gnurou: (it works if I boot my own kernel anyway)
23:24 imirkin: ok, so i fail at selecting network drivers... what driver does it want?
23:25 gnurou: r8169 IIRC
23:25 gnurou: tegra_defconfig should include it I believe
23:25 imirkin: CONFIG_R8169=y
23:25 gnurou: apart from that, things seem to work
23:25 imirkin: my ifc board also fails to come up =/
23:27 gnurou: which kernel config are you using?
23:28 imirkin: mine... it's a combo of tegra and qualcomm
23:28 imirkin: btw is all the regulator junk in the dmesg that you got normal?
23:29 gnurou: yeah, deferred probing... this happens a lot on ARM
23:29 imirkin: tegra-pcie doesn't seem to come up
23:29 imirkin: and that's where the r8169 lives right?
23:29 gnurou: if you want a safe kernel to test, try 4.0-rc3 with tegra_defconfig
23:29 gnurou: should boot like a breeze
23:32 imirkin: do i need to turn on all the TI regulators?
23:34 imirkin: [how can i tell that stuff from the dts?]
23:46 gnurou: err regulators should be turned on by the kernel code when necessary ; I'm not sure I understand your question
23:47 imirkin: i meant the config options
23:47 imirkin: i think i figured out which one was actually needed
23:47 imirkin: based on the dts
23:50 imirkin: w00t, it works
23:50 imirkin: or at least... doesn't completely fail :)
23:52 imirkin: gnurou: let me know if you see something totally amiss: http://hastebin.com/raw/hulerisoqe