00:04gnurou: robclark: unaccelerated X should work out-of-the-box with modesetting. For GLamor, you need to patch X (or any DRM app for that instance) to use PRIME and tell tegradrm about the tiled format used by GPU buffers
00:05gnurou: robclark: https://github.com/Gnurou/xserver/commits/gk20a has a (horrible) hack that does this
00:06gnurou: robclark: sadly it also requires one last out-of-tree kernel patch to receive the buffer format information through a FB modifier: https://github.com/Gnurou/linux/commit/8b06bf92b8da6bee92c3a2a8eaccd74ed3dd1939
00:06gnurou:should probably try to upstream that last one
00:07mupuf: gnurou: we should probably work with lucas on an upstream solution for this
00:07mupuf: this is really annoying not to have X or wayland support out of the box
00:08mupuf: anyway, bedtime!
00:08gnurou: mupuf: I believe https://github.com/cubanismo/allocator will be the solution to this (and a few other problems)
00:09gnurou: mupuf: good night!
03:28imirkin: mupuf: i force-pushed a fix. try again.
04:26iterati: hi, I receive: nouveau 0000:01:00.0: DRM: failed to create kernel channel, -22
04:26iterati: but not if I use external nvidia firmware
04:27iterati: hopefully with that firmware the crical GR engine freeze error will be fixed
04:27iterati: imirkin: it's 650
04:27imirkin: ah right
04:27imirkin: and you're trying it with the blob firmware i pointed you at?
04:28iterati: probably was someone else, but I found https://bugs.freedesktop.org/show_bug.cgi?id=93629
04:28iterati: I extracted the firmware myself
04:30imirkin: right - specifically refer to comment 10 for how to rename it for newer kernels.
04:31iterati: The freeze I am getting is fifo: gr engine fault on channel 12, recovering...
04:31iterati: I think it's recent too, before was working ok, probably 4.7 & 8 kernels, I am not sure though
04:34imirkin: hakzsam: ok, well, looks like i fixed some of those sampler fails but not the compute ones for some reason. haven't investigated. i doubt the issue is in the codegen.
06:54mupuf: imirkin_: where did you force push the fix?
07:01mupuf: gnurou: in the mean time, the nouveau ddx could handle everything, right?
07:01mupuf: it should be easy enough to make a special case
07:02mupuf: and Ilia may have a working maxwell accel
07:02gnurou: mupuf: maybe, but technically the display driver is tegradrm, not Nouveau, so does it make sense to have the Nouveau DDX manage this?
07:02gnurou: mupuf: OTOH I'd be so happy to have a working solution upstreamed...
07:03mupuf: gnurou: IMO, this would not be a problem. But people may have other feelings
07:03mupuf: and if we are not too happy about this, we could hide the code behind a flag
07:04mupuf: but seriously... I doubt this will amount to any serious amount of code
07:04gnurou: mupuf: also, can the Nouveau DDX reuse functions from modesetting?
07:04gnurou: so probably not that easy to do...
07:04mupuf: List all the gpus, see if one is coming from tegradrm, if so, open this one and open the first nvidia GPU left
07:06gnurou: does Nouveau use KMS ioctls to set the video mode on dGPUs?
07:06gnurou: if so, it may work with tegradrm as well, indeed
07:06gnurou:doesn't grok the Xorg DDX internals
07:07mupuf: yes, it does use KMS too
07:07mupuf: so, it should just be a matter of having two sets of open devices: one for rendering and one for display
07:07gnurou: I liked the idea of using modesetting + glamor, but OTOH we should get a noticeable speed gain with Nouveau...
07:08mupuf: modesetting + glamor cannot be upstreamed until we have the new allocator
07:08mupuf: and this is not coming any time soon
07:08mupuf: well, actually, what would be stopping us from using GBM?
07:09mupuf: I really need to spend some time on this and see what we can do
07:09gnurou: nothing, except for the bit where you need to tell tegradrm about the format of the GPU-rendered buffer
07:09gnurou: this requires chip-specific code
07:09mupuf: oh, right
07:09gnurou: if the buffers are linear, you can just use GBM + PRIME and only rely on standard interfaces
07:10mupuf: and this is what everyone is using, but we would lose performance
07:10mupuf: yeah, let's try to fix the nouveau ddx
07:11gnurou: but tiled formats require more information (a FB modifier I guess, although we used a driver-specific ioctl before) and this depends on the chip...
07:11gnurou: I will have a look at this - thanks for the idea!
07:12mupuf: gnurou: everyone just hardcode this, IIRC
07:13gnurou: mupuf: what does "this" refer to?
07:13mupuf: but yeah, the format
07:13mupuf: instead of querying the kernel
07:13mupuf: but we can land a patch to the kernel for this, that would not be a wasted effort ... until we land this new allocator :D
07:16gnurou: actually I may have missed something, but I don't know of a way to know the exact format used by a GPU buffer
07:16mupuf: you can assume it, IIRC
07:17mupuf: per gen
07:17mupuf: we need to check out what Intel and AMD do
07:35hakzsam: imirkin: cool, I will have a look
08:10pmoreau: mupuf: I believe he force-pushed here: https://github.com/imirkin/xf86-video-nouveau
08:11mupuf: pmoreau: obviously he did...
08:16mupuf: imirkin: same problem with your tree
08:20mupuf: imirkin: ~/src/xf86-video-nouveau/ on reator contains the source code with your tree, if you want to make sure this copy error is dealt wit
08:20karolherbst: mupuf: it would be nice to have a maxwell1 inside reator, when I get time, I plan to look into the power budget table
08:20mupuf: karolherbst: see if hakzsam is OK with it
08:20hakzsam: no problem
08:21karolherbst: k thanks
08:21karolherbst: have to figure out why our power readings are a little higher
08:22karolherbst: not that this is a problem
08:22karolherbst: or were they lower? no clue
08:25hakzsam: mupuf: out of curiosity, does this help http://hastebin.com/uqemajumoz ?
08:28mupuf: hakzsam: I let you try, I am at work ;)
08:28mupuf: just go to src/xf86-video-nouveau, apply your patch then make install
08:28mupuf: then start X, check your logs
08:28mupuf: make uninstall when you are done
08:28hakzsam: oh btw you should not unplug the maxwell2 until accel works :)
08:31hakzsam: mupuf: my patch seems to improve the situation
08:32pmoreau: I did not know about stg, but I do know about ldg
08:32pmoreau: (If it's the same as the __ldg() intrinsic in CUDA)
08:32hakzsam: mupuf: what was the issue before?
08:33mupuf: NOUVEAU(0): Failed to initialise context object: COPY_NVE0 (0)
08:33hakzsam: pmoreau: stg is similar to ldg but for stores :)
08:33hakzsam: mupuf: okay, that error has gone
08:33pmoreau: Well, __ldg() in CUDA is for const values, so how would a store to const work?
08:34pmoreau: Some doc for __ldg: http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#ldg-function
08:35hakzsam: ldg/stg uses the new non-coherent global addr space which uses the texture path instead
08:35pmoreau: Accesses are cached in a separate, read-only cache, from regular global mem reads.
08:35hakzsam: _ldg() could be used for loading data from the driver const buf for example
08:35hakzsam: and blob seems like to use stg() all the time
08:36pmoreau: It looks like stg is not exposed in CUDA… let's have a look at the PTX ISA and maxas
08:37hakzsam: maybe not
08:37hakzsam: anyway, should be nice to write a micro benchmark and compare ldg with ld
08:38hakzsam: and stg vs st as well
08:40pmoreau: I know that CUDA devs recommend to use ldg whenever possible, and I try to follow that, but I haven’t really measured the difference.
08:41pmoreau: It will be affected by how each cache is being filled and how the application uses it as well.
08:44hakzsam: imirkin: http://hastebin.com/uyubuwazep --> this fixes mupuf's issue (probably not 100% accurate, but it's a quick fix)
08:47hakzsam: I wonder why it doesn't already fail on gK110 though
09:29hakzsam: gnurou: you don't have this error "NOUVEAU(0): Failed to initialise context object: COPY_NVE0 (0)" when starting DDX? oO
09:43mupuf: hakzsam: he uses the modesetting driver
09:44mupuf: hakzsam: you do not need to allocate a new object for GK110+?
09:44hakzsam: we don't do that in mesa
09:45hakzsam: as I said, it's really a quick fix, imirkin will work on it :)
09:46mupuf: ack :)
11:02hakzsam: imirkin: some dEQP tests with samplers+compute fail for weird reasons.. I don't get what's wrong
11:09hakzsam: imirkin: only with shadow though, interesting
12:55gnurou: hakzsam: mupuf: you mean with GM206/Nouveau DDX?
13:29imirkin: gnurou: mupuf: you guys seem to disagree on whether it's working...
13:30imirkin: hakzsam: oooops. i knew i'd forgotten something. i'll fix it.
13:30hakzsam: for what? samplers?
13:30gnurou: imirkin: I will re-check tomorrow, but pretty confident I ran it correctly...
13:31imirkin: hakzsam: no, for the a0b5 thing
13:31hakzsam: imirkin: ah right :)
13:32imirkin: hakzsam: your fix may actually be the correct one
13:32imirkin: i'll think on it.
13:32imirkin: we still need to create the object for the CE channel thing
13:32hakzsam: yeah, probably not 100% accurate
13:33imirkin: but i believe the one you fixed is concerned with the gr-based one
13:34imirkin: gnurou: what did you run btw? the patches on the ML or the patches in my branch? if the patches on the ML, i assume it ran but accel was disabled.
13:34gnurou: imirkin: patches on the ML actually
13:34gnurou: ok, let me retry with your branch tomorrow
13:35imirkin: super. we have a NvCOPY and NvCopy. not confusing at all.
13:51imirkin: well, i'm not 100% convinced that what we do in mesa is 100% right. easy enough to fix up in xf86-video-nouveau though - i've force-pushed again
13:52imirkin: gnurou: mupuf: have another look when you get a chance. repo at https://github.com/imirkin/xf86-video-nouveau/
15:54gp107nv137: https://nouveau.freedesktop.org/wiki/CodeNames/#nv130familypascal please update this with http://www.geforce.com/hardware/10series/geforce-gtx-1050 NV137 GP107
15:56imirkin_: what makes you say that it's a GP107?
15:57imirkin_: (and not GP106)
15:57gp107nv137: Because it is GP107? http://www.anandtech.com/show/10768/nvidia-announces-geforce-gtx-1050-ti-gtx-1050
15:57gp107nv137: "NVIDIA is launching two cards – both of which are based on the new GP107 – which setup a two-tier product offering for the entry level market."
15:57imirkin_: i was missing that bit of info ;)
15:59imirkin_: updated, thanks
19:27karolherbst: mupuf: doesn't have to be the second thing 0x0d4?
19:35karolherbst: Jaga: updated version: https://gist.github.com/karolherbst/4341e3c33b85640eaaa56ff69a094713
19:36karolherbst: I think I worked through everything you said and ignored some bits I didn't feel strong about, like the userspace library not being tool, cause it also is. Not as in being a executable you can use, but more like a Tool you can use to RE the driver/device/vbios
19:39Jaga: karolherbst: reading it now
19:40Jaga: nvalist - put the sentence explaining what it does first, then add the comment about -c flag; if you want to show an example, maybe put an example of actual output, the $index is somewhat confusing
19:41karolherbst: better idea: I merge both sentences in one
19:41Jaga: just start with the one that explains it first :)
19:42Jaga: typo: Allthough should be Although, also again better start with explanation what nvagetbios does, then add comments how reliable it is
19:44Jaga: is there a way to do more math-like notation in github text? the formula could look better that way (with actual multiplication dot, instead of *)
19:47karolherbst: I don't care about github, I don't plan to leave it there, it is just simple to edit and doesn't look too bad for spending like no effort
19:47karolherbst: I don't think we decided on any platform we want to post stuff like this yet
19:48karolherbst: If we decide on github for whatever reasons, I will spend more time on layouting though
19:48Jaga: so, can you use math signs in formulas or not?
19:48karolherbst: no idea. It is plain text, so maybe as long as it is UTF-8
19:49karolherbst: I focus more on actual content for now, so things like this have to wait until we decide where to post this
19:49karolherbst: maybe the other platform can't handle that
19:49Jaga: as you wish
19:50karolherbst: maybe we do it in tex in the end, cause we want to generate awesome PDFs :D
19:50karolherbst: uhh embedded videos in PDFs, is that a thing yet?
19:51Jaga: can you print the so they keep playing?
19:51karolherbst: when reality gets me....
19:51karolherbst: but sure, why not
19:52Jaga: about this line ((3072 * 0x10 - 2) * 0x100) | 0x9 = 0xbffe09 => nvapoke 0x619f04 0xbffe09
19:52Jaga: would be nice to have a better indication where calculation ends and where you take the value and substitute in the command, now it kinda looks like you're doing a larger equation with logical =>
19:53karolherbst: mhhh, right
19:54Jaga: I'd say doing stuff like file names, directories and calculations in italics could help
19:55karolherbst: already changed that
19:55karolherbst: it's not italics though
19:55karolherbst: but this `` thing
19:55karolherbst: uhh, forgot a few
19:55Jaga: aa, better
19:55karolherbst: the pain about markdown is the new line thing...
19:56Jaga: well, once you apply it in one place you might want to go after all similar things in the whole text, for the sake of uniformity
19:56karolherbst: the example nvalist output is actually three lines, but meh
19:56karolherbst: ``` instead of ` helps
19:58Jaga: in the example above modprobe
20:00karolherbst: it is more text though, still looks odd
20:01karolherbst: ohh, I have an idea
20:05karolherbst: anything else?
20:05Jaga: not putting modprobe higher?
20:06karolherbst: well, strictly I just write about the -r feature. I kind of expect somebody who wants to read this, to know what at least modprobe is, maybe it is too much to hope for :(
20:07Jaga: well, if that's your assumption you can keep it
20:09karolherbst: no idea, I can't really judge how many linux users know modprobe
20:09Jaga: The sentence "To RE the vbios.." in Process irks me a bit, I'd rewrite it, just not sure how exatly
20:10karolherbst: but somehow I assume if you really want to start hacking on a linux kernel module, you should at least know insmod, modprobe and rmmod
20:10Jaga: it's a bit too long
20:10karolherbst: I started to write "reverse engineer" anyway :D
20:10karolherbst: RE sounds kind of not well
20:11karolherbst: long sentence indeed though
20:11Jaga: shorter sentences are better understood
20:12Jaga: typo: reproduciable -> reproductible
20:14Jaga: assumptions, which can be approved <- this sentence can be split too like "assumptions. They can be approved..."
20:15Jaga: good to see the example script, the comment could be reformed tho to leave the ? out, and make it like a theory "reads out PWM0 and PWM1 state to detect changes to see if fans are controlled through them"
20:16karolherbst: "Required for effective reverse engineering of the vbios it is a stable and reproducible test to confirm a change within the Nvidia kernel module." ? It somehow drifted far away from the thing I actually wated to say with this though :/
20:16karolherbst: you know what, the sentence doesn't add any value anyway
20:17mwk: what are you guys doing?
20:17karolherbst: check out that awesome link
20:17Jaga: A stable testing environment is essential to vbios and RE testing.
20:18Jaga: ^ that's first part, I have trouble coming with the second part
20:18imirkin_: mwk: sounds like they're creating a "how to go from knowing nothing about nvidia or linux to being an expert at RE in 5 minutes"
20:18karolherbst: imirkin_: exactly
20:18mwk: now that sounds easy
20:19karolherbst: well, it is more of a collection on things you actually need
20:20karolherbst: I always feel kind of bad if I talk to interested people wanting to help out and they have no clue how to start and basically have to ask here for pointers
20:21imirkin_: call me an old fart if you must, but these youngin's expect everything to be point-and-click now. "figure it out" doesn't seem to be in their bag of tricks.
20:21karolherbst: imirkin_: uhh there is a lot of potential of figuring out things
20:21imirkin_: if you're having to explain what modprobe does
20:22karolherbst: I don't
20:22imirkin_: then the guide is not for the right people :)
20:22karolherbst: I just say instead of rmmod all the deps, use modprobe -r with that script below
20:22karolherbst: it is fun, but nobody actually has a working script, except me...
20:22karolherbst: even bumblebee uses libkmod now....
20:22Jaga: imirkin_: you're looking from the wrong point - you don't get people (even intelligent ones) interested in stuff unless there's documentation and you don't need to bother others about it
20:23imirkin_: Jaga: i'm not arguing against having docs, and i'm not suggesting that nouveau has well-organized docs
20:23imirkin_: Jaga: but this stuff is hard. it's complex. and it's poorly understood. writing clear documentation is a difficult task.
20:23karolherbst: also I wouldn't even think about documenting modprobe here as I already said above ;)
20:23imirkin_: i tried once, but quickly understood i understood nothing
20:23karolherbst: imirkin_: right, that's why I mainly document the tools
20:24Jaga: imirkin_: you kinda sound like you're suggesting that since it's hard, writing documentation is a waste
20:24imirkin_: not at all
20:25imirkin_: more like coming up with excuses for why it doesn't exist
20:25karolherbst: allthough not caring enough is also a valid one here :p
20:25Jaga: imirkin_: well, I can invent a lot of excuses based on experience, not even on what nouveau does :p
20:25karolherbst: which mostly is the real reason in the end
20:25RSpliet1: I think not caring enough can be phrased more accurately as "it's somewhere at the bottom of everyones long long todo list"
20:26karolherbst: RSpliet1: :D
20:26karolherbst: right cause otherwise it would be higher!
20:26Jaga: RSpliet1: which happens relatively often in many projects
20:26imirkin_: however the driving force behind RE is to want to figure stuff out
20:26imirkin_: so a lack of docs shouldn't be particularly discouraging
20:26pmoreau: HerrSpliet: You moved to Germany? :-D
20:26karolherbst: imirkin_: mhhhhhh... why you do this? :D
20:26karolherbst: pmoreau: no, it is simply his troll nick
20:27pmoreau: Oh, didn’t know that
20:27Jaga: imirkin_: lack of docs and info online does give an impression tho that the project is half dead
20:27imirkin_: karolherbst: for fun, definitely not profit :)
20:27karolherbst: can't expect anything valueable from somebody calling himself HerrSpliet on the interwebs :p
20:27imirkin_: Jaga: eh .. it kind of is.
20:27HerrSpliet: "troll" -> "second nick when RSpliet is taken" (by a different machine for instance). More original than <nick>1
20:27pmoreau: imirkin_: Do you have any additional comments on top of Ian’s one? Since he’ll be pushing a similar patch for GLSL, should I keep it within my translation pass rather than having it in nouveau compiler?
20:27karolherbst: HerrSpliet: or your machine at home decides to turn on by itself :p
20:27pmoreau: HerrSpliet: ;-)
20:28Jaga: imirkin_: and do you want people to have that impression then? cause I don't think it would attract more people to help
20:28imirkin_: pmoreau: i dunno, i'll think about it i guess
20:28imirkin_: Jaga: or it'd attract people more since they'll feel like this project actually needs help
20:28pmoreau: Ok. I was going to send out the v3, but I’ll wait then. :-)
20:29imirkin_: Jaga: either way, nothing i'm saying is arguing against writing docs
20:29Jaga: imirkin_: ok
20:29pmoreau: imirkin_, Jaga: The firmware situation isn’t really helping either
20:29imirkin_: but trying to come up with a "RE guide" is not something that can be achieved without a *significant* time investment
20:29karolherbst: pmoreau: true, and I use every excuse to mention that this sucks :p
20:30hakzsam: karolherbst: did you try playing metrox 2033 redux recently? it's "playable" here
20:30HerrSpliet: karolherbst: what might be a helpful first start on the short term (that is potentially easier) is having a proper help text "in" every envytools tool that explains the params when -h is passed or sth
20:30karolherbst: hakzsam: uhhh sure?
20:31karolherbst: hakzsam: did you reply my trace?
20:31hakzsam: karolherbst: yeah, didn't get the issue
20:31karolherbst: hakzsam: the trace, at least last time I tried, grabbed like 5GB of ram
20:31karolherbst: maybe it is fixed now
20:31karolherbst: I would even bisect
20:31hakzsam: I hit the issue only one time actually
20:31karolherbst: HerrSpliet: true
20:31hakzsam: but I played only few minutes
20:31imirkin_: some kind of reorg + judicious deletion of these pages would be great: https://nouveau.freedesktop.org/wiki/Development/ + https://nouveau.freedesktop.org/wiki/IntroductoryCourse/
20:33karolherbst: hakzsam: well, a few minutes is already better than oom in the main menu ;)
20:34karolherbst: imirkin_: docs about the kernel module would be also nice
20:34karolherbst: at least for the architecture
20:34imirkin_: yes... i gave up on that thought when ben started rewriting it every 2 kernels
20:35imirkin_: although i think he's stopped now
20:35karolherbst: yeah, makes sense
20:35karolherbst: the current design seems good enough for now
20:35imirkin_: the design from 3.8 seemed fine too
20:35HerrSpliet: for the next six months ;-)
20:35pmoreau: Maybe still some more coming with atomics? Dunno how much needs to be changed
20:35karolherbst: the prior design sucked a bit
20:36karolherbst: the current one is much more type safe, which is a big win
20:36karolherbst: HerrSpliet: uhh, then it is time again actually!
20:36pmoreau: Do we still need GF1xx, GKxxx MMIOtraces? https://nouveau.freedesktop.org/wiki/TestersWanted/
20:37karolherbst: pmoreau: only from special ones for kepler
20:37karolherbst: and the special ones are in front of ben every day
20:37hakzsam: pmoreau: we need MMT traces for compute on pascal :p
20:38pmoreau: hakzsam: I was willing to do that, unfortunately the traces were corrupted ;-p
20:38hakzsam: I know
20:38karolherbst: pmoreau: do you have a GGDR5 based pascal somewhere?
20:38pmoreau: karolherbst: Got a 1080 at work
20:39karolherbst: i don't care for gddr5x
20:39pmoreau: karolherbst: So no funky reclocking testing! :-p
20:39pmoreau: Oh, yeah, I misread the GDDDR5 to GDDR5X
20:39karolherbst: well, pascal is the next thing
20:39karolherbst: maxwell is pretty much done except the shit situation
20:39karolherbst: so yeah :p
20:40karolherbst: the SEQ script of the gddr5x one looked pretty much sane though
20:40karolherbst: I doubt we will have big troubles with those
20:40karolherbst: it just somewhere else mainly
20:40karolherbst: the mmio space
20:41karolherbst: gddr5x will be just a bit messy cause it has a single/duoble/quad pumped modes
20:41karolherbst: will be fun though I guess
21:04mwk: well, here goes
21:05mwk:managed to do a demand-paged DMA write on NV1
21:05mwk: the process is weird, but easy
21:53HerrSpliet: pmoreau: I *think* NVIDIA shuffled around the IOCTLs in their latest driver releases - demmt doesn't know what to read and possibly valgrind-mmt doesn't know what to intercept
21:54imirkin_: yeah, that's been going on for a while
21:54imirkin_: and/or with their newer gpu's
21:56hakzsam: yeah, we can't trace pascal
22:02HerrSpliet: should be fixable with a few days of fiddling with the tools. Who has a few days spare? :-P
22:04airlied: imirkin_: any luck on those traces
22:05imirkin_: airlied: haven't looked yet
22:05imirkin_: airlied: may or may not tonight
22:05imirkin_: [tending towards not as of now]
22:06airlied: oh I wasn't sure when tonight started :-P
22:06imirkin_: "tonight" is secret code for "later" :)
22:06imirkin_: (but now the secret's out...)
22:14imirkin_: airlied: i fixed some indirect sampler junk on maxwell though :) i bet that'd fix a bunch of tests if you had run it on there.
22:18airlied: imirkin_: the effort to make cts run on another machine is more than I have :-P
22:18imirkin_: i wasn't suggesting you would
22:18imirkin_: just saying i haven't been completely sitting on my hands :)
22:41hakzsam: mupuf: ping
22:42hakzsam: mupuf: can you get rid of the weird titan and plug a Kepler1 instead?
22:42hakzsam: as well as the Maxwell1 for karol
23:42feliksk: im the guy with the nvidia gt 440 fan noise
23:42feliksk: i compiled a 4.4.23 kernel (with help from distribution specific configuration file meant FOR that kernel) and the noise is still there
23:43feliksk: should i try to compile the latest kernel possible to see if it has been fixed?
23:43feliksk: i am just talking about the nouveau kernel module for now, i dont care about the X stuff at the moment
23:49feliksk: i will try compiling a linux 4.9-rc1, i have no idea what im doing here so it'l probably fail
23:49feliksk: the 3.10 something kernels didn't have fan noise on my gt 440 card
23:52ShimmerFairy: feliksk: I don't know anything about the fan noise issue, but for compiling a new kernel one thing you could do is copy your 4.4.23 kernel's .config file to the same place in 4.9's source, and then run 'make oldconfig' or 'make silentoldconfig' to update the .config file
23:53ShimmerFairy: the difference between the two is that 'oldconfig' will ask you how you want to set new options, whereas 'silentoldconfig' (I believe) will just set all the new options to default values automatically.
23:57feliksk: make silentoldconfig prompts me with a lot of stuff
23:58feliksk: should i do 'make bzImage modules' or just 'make'?
23:59feliksk: im doing 'make bzImage modules'