--- Log opened Пнд Сен 25 00:00:47 2006
00:07 -!- EdB [n=EdB@ARennes-251-1-32-111.w81-250.abo.wanadoo.fr] has quit ["Konversation terminated!"]
00:27 -!- pmdata [i=patrice@ANantes-154-1-27-129.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
00:39 -!- hiyuh [n=hiyuh@KD125054017176.ppp-bb.dion.ne.jp] has quit ["Leaving"]
01:09 -!- johnnybuoy [n=void@unaffiliated/johnnybuoy] has joined #nouveau
01:11 -!- Myrizio [n=Myrizio@Linuz.sns.it] has joined #nouveau
01:26 -!- nael [n=nael@ras75-1-81-57-62-96.fbx.proxad.net] has quit [Read error: 110 (Connection timed out)]
01:31 -!- flex [n=flex@194.23.101.92] has left #nouveau []
01:35 -!- johnnybuoy_ [n=void@nilus-1746.adsl.datanet.hu] has joined #nouveau
01:38 -!- johnnybuoy [n=void@unaffiliated/johnnybuoy] has quit [Read error: 60 (Operation timed out)]
01:39 -!- johnnybuoy_ is now known as johnnybuoy
01:39 -!- Duke` [n=gnu@ANantes-251-1-89-184.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
02:17 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
02:23 -!- cetrox [i=cetrox@74-247-222-201.adsl.terra.cl] has quit [Remote closed the connection]
02:23 -!- cetrox [i=cetrox@74-247-222-201.adsl.terra.cl] has joined #nouveau
02:23 -!- rem [i=rem@ALyon-252-1-62-229.w82-122.abo.wanadoo.fr] has quit ["dodo"]
02:59 -!- predatorfreak [n=predator@adsl-75-46-41-247.dsl.sfldmi.sbcglobal.net] has joined #nouveau
03:38 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has joined #nouveau
04:30 -!- Unbeliever [n=hazel@84-16-252-194.internetserviceteam.com] has joined #nouveau
04:32 -!- johnnybuoy [n=void@nilus-1746.adsl.datanet.hu] has quit ["Leaving"]
04:32 -!- johnnybuoy [n=void@unaffiliated/johnnybuoy] has joined #nouveau
04:34 -!- johnnybuoy is now known as johnnybuoy|plan9
04:34 -!- johnnybuoy|plan9 is now known as johnnybuoy
04:51 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has quit [Read error: 104 (Connection reset by peer)]
04:55 -!- Unbeliever [n=hazel@84-16-252-194.internetserviceteam.com] has quit [Remote closed the connection]
04:58 < marcheu> woo I just got a context switch interrupt
04:58 < darktama> :) !!
04:58 < marcheu> now all I have to do is service it:)
04:58 < darktama> what did you need to do to get that?
04:59 < marcheu> hah, not sure what was the missing piece
04:59 < marcheu> but one thing I'm almost sure is it won't work on nv40, which might be why you had issues
04:59 < marcheu> the interrupt bits are different from nv40
05:00 < marcheu> unknown PGRAPH interrupt 0x1000 that's it, right ?
05:00 < darktama> yup, bit 12 iirc
05:00 < marcheu> cool
05:00 < marcheu> I'm working with the nv11 right now
05:01 < marcheu> hmm 3am... is it reasonable writing the interrupt service code now...
05:01 < darktama> haha, sure it is!
05:02 < marcheu> luckily I'm insomniac
05:04 < marcheu> btw we have to decide if we leave the REINIT code or not
05:05 < marcheu> do you think we might get away without it ?
05:05 -!- hiyuh_work [n=hiyuh@ZQ176172.ppp.dion.ne.jp] has joined #nouveau
05:05 < darktama> I think we should get rid of it.. That is, if we can do it without causing lockups
05:06 < marcheu> do crashes on VT switches count as lockups ?
05:06 < darktama> hmm, probably :)
05:08 < marcheu> nvidia probably power down the card completely on VT switches
05:08 < darktama> hmm, lets see
05:08 < marcheu> because things like offscreen rendering don't work any more when you're switched away from X
05:09 < darktama> nope, PFIFO is at least kept powered up
05:10 < marcheu> hmmm, weird
05:10 < marcheu> did you try a glxinfo while switched away from X ?
05:10 < marcheu> says "forceSW"
05:10 < marcheu> in GL_RENDERER
05:10 < darktama> yup, I see that..
05:11 < darktama> interesting...
05:11 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has joined #nouveau
05:11 < marcheu> that's what raised my suspicion
05:13 < darktama> no rendering seems to occur, the PUT/GET pointers don't advance when vt-switched away
05:13 < marcheu> well, it's software rendering :)
05:13 < marcheu> I'm not sure why, though
05:18 < marcheu> ok, I also reenabled the interesting register tests
05:18 < marcheu> I think it'll help us understand the differences on nv40
05:19 < darktama> hmm, I might also add 0x2214/0x2218/0x2220 there for nv40
05:20 < darktama> oh, the first two are already there
05:21 < marcheu> hmm are these different on nv40 ?
05:22 < darktama> I'm wondering how PFIFO_RAMHT looks when there's a RAMIN mirror and when there isn't
05:22 < marcheu> ah right
05:22 < darktama> and 0x2220 I suspect is PFIFO_RAMFC on nv40
05:30 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has quit [Remote closed the connection]
05:46 -!- Gusar_ [n=Gusar@cpe1-23-67.cable.triera.net] has joined #nouveau
05:46 -!- Gusar [n=Gusar@cpe1-23-67.cable.triera.net] has quit [Read error: 104 (Connection reset by peer)]
06:04 < marcheu> hmm what is 0x714000 ?
06:04 < darktama> part of RAMIN
06:04 < marcheu> ah right
06:04 < marcheu> tiredness starts to show :)
06:09 < darktama> hmm, it's the middle of the day and I'm already starting to make silly mistakes :)
06:09 -!- darwah [n=cool@ip-193.net-81-220-103.nantes.rev.numericable.fr] has joined #nouveau
06:09 < darwah>  tin ya des francais ici???
06:10 < marcheu> yeah, but not all french people speak with colors though
06:10 < darktama> lol
06:12 < darwah>  g vu
06:12 -!- darwah [n=cool@ip-193.net-81-220-103.nantes.rev.numericable.fr] has left #nouveau []
06:27 -!- johnnybuoy [n=void@nilus-1746.adsl.datanet.hu] has quit ["Leaving"]
06:32 < marcheu> it's weird that nvosdk reads get/put from 714000 though
06:33 < darktama> hmm, it does? where
06:33 < marcheu> well, gr_nv04.c
06:33 < marcheu> in the middle of the context switch interrupt servicing code :)
06:33 -!- hiyuh_kuma [n=hiyuh@ZK138164.ppp.dion.ne.jp] has joined #nouveau
06:33 < marcheu> put = ((hwreg)->Reg32[(0x714000 + i * 32) / 4]);
06:33 -!- hiyuh_kuma [n=hiyuh@ZK138164.ppp.dion.ne.jp] has quit [Read error: 54 (Connection reset by peer)]
06:34 < darktama> hmm, that might not be strange - depending on where nvosdk puts RAMFC
06:34 < marcheu> not at 14000 if that's what you think
06:36 < marcheu> it's at 0x00700000 + 0x1200
06:37 < darktama> yup.. interesting
06:38 < marcheu> yeah, I was expecting put and get to be the first to RAMFC entries
06:38 < marcheu> first two
06:38 < darktama> they are afaict
06:39 < marcheu> yes, so what's at 714000 ?
06:40 < darktama> hmm, I have no idea.. I can't see anything obvious yet
06:41 -!- hiyuh_work [n=hiyuh@ZQ176172.ppp.dion.ne.jp] has quit [Read error: 60 (Operation timed out)]
06:55 -!- Myrizio [n=Myrizio@Linuz.sns.it] has quit ["I like core dumps"]
07:01 < marcheu> hmm we don't have a kernel-side wait_for_idle yet
07:03 -!- hiyuh_work [n=hiyuh@ZK138164.ppp.dion.ne.jp] has joined #nouveau
07:54 -!- johnnybuoy [n=void@unaffiliated/johnnybuoy] has joined #nouveau
08:24 -!- Gusar_ [n=Gusar@cpe1-23-67.cable.triera.net] has quit ["leaving"]
09:01 -!- hiyuh [n=hiyuh@ZQ175089.ppp.dion.ne.jp] has joined #nouveau
09:05 -!- tibbs is now known as tibbs|h
09:09 -!- hiyuh_work [n=hiyuh@ZK138164.ppp.dion.ne.jp] has quit [Read error: 60 (Operation timed out)]
09:10 -!- hiyuh [n=hiyuh@ZQ175089.ppp.dion.ne.jp] has quit [Read error: 60 (Operation timed out)]
09:14 -!- Duke` [n=gnu@ANantes-251-1-89-184.w86-203.abo.wanadoo.fr] has joined #nouveau
09:24 -!- hiyuh_work [n=hiyuh@KD059133117061.ppp.dion.ne.jp] has joined #nouveau
09:30 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
10:25 -!- johnnybuoy [n=void@unaffiliated/johnnybuoy] has quit ["Leaving"]
10:46 -!- __sha__ is now known as shaAway
11:08 -!- EdB [n=EdB@ARennes-251-1-89-174.w86-199.abo.wanadoo.fr] has joined #nouveau
11:45 -!- shenki [n=shenki@ppp99-165.lns4.adl2.internode.on.net] has joined #nouveau
11:51 -!- Gusar [n=Gusar@e-74.vc-graz.ac.at] has joined #nouveau
13:15 -!- cetrox_ [i=cetrox@196-243-222-201.adsl.terra.cl] has joined #nouveau
13:19 -!- predatorfreak [n=predator@adsl-75-46-41-247.dsl.sfldmi.sbcglobal.net] has quit ["<blank>"]
13:20 -!- cetrox [i=cetrox@74-247-222-201.adsl.terra.cl] has quit [Read error: 60 (Operation timed out)]
13:40 -!- rem [i=rem@ALyon-252-1-52-118.w82-122.abo.wanadoo.fr] has joined #nouveau
13:40 < rem> hello
14:45 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
15:03 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has joined #nouveau
15:29 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
15:50 -!- Duke` [n=gnu@ANantes-251-1-89-184.w86-203.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
15:51 -!- Duke` [n=gnu@ANantes-251-1-123-162.w86-210.abo.wanadoo.fr] has joined #nouveau
16:12 -!- johnnybuoy [n=void@unaffiliated/johnnybuoy] has joined #nouveau
16:28 -!- shenki [n=shenki@ppp99-165.lns4.adl2.internode.on.net] has quit ["http://xkcd.com/comics/fourier.jpg"]
17:14 -!- silverpo1er [n=shrike@adsl-234-207-148.cha.bellsouth.net] has joined #nouveau
17:26 -!- silverpower [n=shrike@adsl-234-203-19.cha.bellsouth.net] has quit [Read error: 113 (No route to host)]
17:40 -!- Maduser [n=maduser@d062153.adsl.hansenet.de] has joined #nouveau
17:40 -!- yonibear [n=yonibear@p54A969A3.dip.t-dialin.net] has joined #nouveau
17:42 < Maduser> Hello, I have made dumps from my GeForce FX 5600 (NV31)
17:42 < Maduser> I load then on http://stud.fh-wedel.de/~winf2163/ up
17:42 < Maduser> I have say this some times ago in this channel but The dumps are not in http://nouveau.sourceforge.net/tests/
17:43 < Maduser> is this normal or was the right one not there
17:44 < marcheu> hmm, there's not "right one" most devs can upload dumps
17:44 < marcheu> I'll take care of that
17:44 < marcheu> is all.tar.bz2 all I need to download ?
17:44 < Maduser> yes the all.tar.bz2 include all tests
17:45 -!- johnnybuoy [n=void@unaffiliated/johnnybuoy] has quit [Read error: 54 (Connection reset by peer)]
17:45 < Maduser> thank you
17:46 < marcheu> done, thanks
17:46 < Maduser> fine
17:46 < marcheu> hmm
17:47 < marcheu> would you mind running the interesting reg test please ?
17:47 < marcheu> the very latest one, it's in renouveau CVS
17:49 < Maduser> okey I will do this and message you
17:49 < marcheu> cool thanks
17:50 < marcheu> I am going to need it to figure out some of the context switching and interrupt code on different cards
18:12 < Maduser> Okey I have upload ist
18:13 < Maduser> I put every file again online
18:13 < Maduser> and the all.tar.bz2 contains all
18:33 -!- hiyuh_work [n=hiyuh@KD059133117061.ppp.dion.ne.jp] has quit ["Leaving"]
18:34 < marcheu> ok, done again, thanks
18:37 < Maduser> no Problem, thank you for working for a free driver
18:37 -!- Maduser [n=maduser@d062153.adsl.hansenet.de] has left #nouveau []
18:51 -!- silverpo1er [n=shrike@adsl-234-207-148.cha.bellsouth.net] has quit ["leaving"]
18:52 < Gusar> hi, I've created dumps from my Geforce Go 6600 (nv43), get them here http://student.dcu.ie/~vamplu2/renouveau/nv43m_tests.tar.bz2
18:53 -!- Myrizio [n=Myrizio@Linuz.sns.it] has joined #nouveau
19:04 -!- hiyuh [n=hiyuh@KD125054017176.ppp-bb.dion.ne.jp] has joined #nouveau
19:09 -!- phh [n=phh@moi.phhusson.info] has joined #nouveau
19:10 < marcheu> ok, done too, thanks
19:26 < marcheu> why should we read get/put from 0x714000 (where they don't seem to be, they dont seem to appear within the 0x71???? range at all) and not from NV03_FIFO_REGS(i) ? 
19:26 < marcheu> 714000 really looks like some scratch area
19:27 < darktama> I'm wondering if it's a bug.. it really doesn't make any sense.. 0x714000 is *definitely* RAMIN.. we could put an object instance there if we wanted
19:28 < marcheu> hmmm
19:28 < marcheu> what area does RAMIN span exactly ?
19:28 < darktama> as far as I know, 0x700000->0x7FFFFF
19:28 < marcheu> hahaha. very funny
19:28 < darktama> I haven't tested that though
19:29 < marcheu> but is that the area where we put instances ?
19:29 < marcheu> I mean, do we cover that whole area ?
19:29 < marcheu> RAMFC/RAMRO need some place to live in here as well...
19:30 < darktama> we start putting instances from +0x12000
19:30 < darktama> our hash table is at +0x11000
19:31 < marcheu> ah, reasons fro crashes become clearer now :)
19:31 < darktama> oh, wait.. hash table is at 0x10000 for us sorry
19:31 < marcheu> I have RAMFC at 0x11000 here, and RAMRO at 0x11200
19:32 < darktama> yup, that's how the xorg ddx set it up
19:32 < darktama> s/xorg/nv/
19:32 < marcheu> we don't have much choices where to put it
19:35 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has quit [Remote closed the connection]
19:35 < darktama> nope, not really..
19:38 -!- Myrizio [n=Myrizio@Linuz.sns.it] has quit ["I like core dumps"]
19:40 < marcheu> hmm NV03_FIFO_REGS(i) doesn't seem to move either
19:41 < darktama> for the second channel?
19:41 < marcheu> for the first
19:41 < darktama> oh.. that's odd
19:41 < marcheu> it's supposed to be 0x800000 right ?
19:42 < darktama> oh, I misread that.. I thought you were talking about the GET/PUT pointers in the regs
19:42 < marcheu> ah non 0x800040 
19:42 < darktama> what do you mean by it doesn't move?
19:42 < marcheu> yes, the GET/PUT pointers
19:43 < darktama> so, 0x40/0x44 move then? :)
19:43 < marcheu> yes :)
19:43 < darktama> hehe, good!
19:43  * marcheu ie releived
19:43 < marcheu> now, I wonder if I can use that instead of 714000
19:43 < marcheu> I'd think so
19:44 < darktama> yeah, I don't see why not
19:44 < darktama> you could even use CACHE1_DMA_GET/PUT if the channel is active
19:44 < marcheu> actually, I need if for all the channels
19:45 < marcheu> what the nvosdk does is look at all get/put for all fifos, and when they differ, deduce that it means the fifo needs scheduling
19:45 < marcheu> then writes liveness fifo information to that mysterious PENDING reg, which I'm not sure if it doesn anything yet
19:46 < darktama> hmm, do you know what CACHE1_DMA_PENDING is for then?  I figured that was a mask of channels where PUT is more advanced than GET
19:46 < darktama> oh
19:46 < darktama> you answered that already :)
19:46 < marcheu> well, I thought it was going to schedule for me, but it doesn't look like it
19:46 < marcheu> like, by choosing among the PENDING channels
19:46 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
19:47 < darktama> hm, I'd prefer to have control of when a channel is scheduled anyway.. we can prioritise things then if we need to
19:47 < marcheu> I'm not sure if I have to set the active channel myself then... the nvosdk doesn't do it, but Im inclined to test that
19:48 < darktama> mm, nvosdk does that doesn't it?
19:48 < marcheu> in the context switch handler ? not AFAICS
19:48 < darktama> the gr ctx_switch handler calls fifoFlushContext?
19:49 < marcheu> well I don't think it does, but I'm only looking at the very bottom code
19:49 < darktama> no..
19:49 < darktama> hmm
19:50 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has joined #nouveau
19:52 < marcheu> it does something more annoying though, grLoadChannelContext
19:53 < marcheu> but maybe that's only needed for NV04/NV05
19:53 < darktama> yup, I've mentioned that before.. that has me worried a bit
19:55 < marcheu> I'm not sure if it matters, or if it's 2D only
19:55 < marcheu> I'd say the latter
19:55 < marcheu> if the stuff is common to all rendering, we can just leave it as is
19:56 < darktama> yeah, I guess we won't find out for sure though until we can use multiple channels at once
19:57 < marcheu> also, it looks like the card goes to a special mode if you don't service the context switch interrupt fast enough
19:58 < marcheu> where service seems to mean NV_WRITE(NV_PGRAPH_INTSTAT, NV_PGRAPH_INTR_CONTEXT_SWITCH);
19:58 < marcheu> and then you don't get interrupts any more, andI have to reboot
19:58 < darktama> hm, what is the special mode?
19:59 < marcheu> well, it's interrupt-less mode :)
19:59 < darktama> weird.. any interrupts before it does that?
19:59 < marcheu> no
19:59 < marcheu> and no interrupts at all after that happens
19:59 < marcheu> now maybe that's another bug, but taht's really what it looks like
20:00 < marcheu> maybe we need to enable the timeout interrupts or something :)
20:00 < darktama> I wonder if it's got anything to do with the SINGLE_STEP stuff..
20:00 < marcheu> I hope I don't have it set
20:00 < darktama> actually, it looks like you get an interrupt if that happens
20:01 < marcheu> well you get one for each fifo command I think
20:01 < darktama> yeah, but I imagine the first has to be serviced before you get any more
20:01 < marcheu> yup
20:06 -!- cetrox_ is now known as cetrox
20:07 -!- yonibear [n=yonibear@p54A969A3.dip.t-dialin.net] has left #nouveau ["Ex-Chat"]
20:29 -!- cetrox [i=cetrox@196-243-222-201.adsl.terra.cl] has quit [Remote closed the connection]
20:29 -!- cetrox [i=cetrox@196-243-222-201.adsl.terra.cl] has joined #nouveau
20:34 -!- pmdata [i=patrice@ANantes-154-1-64-191.w81-53.abo.wanadoo.fr] has joined #nouveau
20:46 < titou> hi
20:46 < titou> pmdata: did you found a solution for renouveau on my Itanium machine ?
20:52 < marcheu> renouveau on itanium ?
20:53 < marcheu> I'd be impressed :)
20:53 < titou> marcheu: it doesn't work :)
20:53 < marcheu> I know
20:54 < marcheu> titou: what card do you have on your ia64 ?
20:54 < marcheu> also, what driver version ? It's not maintained since 5xxx IIRC
20:54 < marcheu> and it only works with certain quadro cards
20:55 < titou> a NVidia Quadro 2 Pro
20:55 < titou> ya i know
20:55 < marcheu> although I can only encourage you to try to port it
20:55 < titou> that's why i promote this project to have free drivers for my card: )
20:55 < marcheu> I'd be very interested in seeing the results on ia64
20:55 < titou> since i can't use NVidia proprietary driver because it doesn't work with Xorg..
20:55 < marcheu> ia64 machines are _very_ fragile WRT bus access and thus the driver has to be extra careful for everything
20:56 < titou> they are too old :(
20:56 < titou> i never had troubles with bus access...
20:56 < titou> i don't know why you are saying that
20:57 < marcheu> do you program drivers on that ?
20:57 < titou> no drivers
20:57 < titou> but i program on IA64
20:57 < marcheu> well user space programming just works
20:57 < titou> in a near future i will have to write a specific kernel for that architecture
20:57 < marcheu> but basically, the hw allows zero tolerance with weird access over the bus (and that only the drivers do)
20:58 < marcheu> so if your driver works on ia64, you're basically sure that it works mostly everywhere else :)
20:58 < titou> ok
20:58 < marcheu> cool, what kind of kernel ?
20:58 < titou> a UNIX like kernel
20:59 < marcheu> hmm, may I ask what for ?
21:00 < pmdata> titou> sorry I don't know much more about kernel syscall to help you
21:01 < titou> :(
21:01 < titou> pmdata: it is for you :)
21:01 < titou> if you still have dump for Quadro 2 Pro card, it's ok
21:02 < pmdata> I think it's more interesting to get renouveau to work on other platforms
21:03 < titou> i don't think lots of people have Itanium at home... :))
21:05 < pmdata> but there are people with nvidia cards on win32/64 or macosx
21:05 < titou> ya but it's radically different :)
21:07 < darktama> hmm, I wonder who'd be brave enough to do a win32 port..
21:07 < darktama> I might add it to my "when really bored" list
21:07 < titou> but it would be a good thing to have win32 / 64 port
21:07 < marcheu> well the windows and linux driver are basically the same
21:07 < marcheu> not much interest if you ask me
21:07 < marcheu> OSX however... :)
21:07 < darktama> from an OpenGL viewpoint, there's not much point.. the code is the same.. now, if D3D can do stuff that OGL can't...
21:08 < pmdata> yep, renouveau/d3d could be very interesting
21:08 < darktama> what does d3d offer that ogl can't do btw?
21:08 < marcheu> API changes for every revision ?
21:09 < darktama> ehehe
21:09 -!- shaAway is now known as __Sha__
21:10 < darktama> well, if there's nothing at all.. a D3D port is useless too
21:10 < marcheu> well usually all functionality is exposed through vendor-specific extensions
21:11 < darktama> yup, that's definitely true
21:17 -!- stillunknown [n=stillunk@82-168-177-167.dsl.ip.tiscali.nl] has quit ["Words get written, words get twisted, old meanings change in the drift of time. (sung by Ian Anderson)"]
21:27 -!- stillunknown [n=stillunk@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
22:07 -!- jkolb [n=jkolb@wsi-129-38.wsi.com] has joined #nouveau
22:16 < marcheu> titou: so how's ia64 going ?
22:21 < titou> please wait
22:21 < titou> i'm reinstalling XFree and NVidia drivers
22:22 < marcheu> I'm really interested in seeing what the result will be
22:22 < titou> =)
22:28 -!- __Sha__ is now known as shaAway
22:36 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit [Remote closed the connection]
22:52 -!- johnnybuoy [n=void@unaffiliated/johnnybuoy] has joined #nouveau
23:00 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has quit [Remote closed the connection]
23:07 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has joined #nouveau
23:07 -!- cetrox [i=cetrox@196-243-222-201.adsl.terra.cl] has quit [Remote closed the connection]
23:07 -!- cetrox [i=cetrox@196-243-222-201.adsl.terra.cl] has joined #nouveau
23:12 -!- phh [n=phh@moi.phhusson.info] has quit [Read error: 104 (Connection reset by peer)]
23:44 < titou> does renouveau works under 2.4 kernels ?
23:52 < marcheu> no idea, why ?
23:53 < marcheu> it should, at least I see nothing preventing that
23:53 < titou> since drivers doesn't work at all with my current configuration
23:53 < titou> so i think i will install a new debian to try renouveau
23:54 < titou> but it will be a 2.4 kernel
23:54 < titou> (to have NVidia drivers usable)
23:54 < marcheu> well pmdata has been using renouveau with 2.4, yes
23:54 < titou> hm k
23:56 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit ["Les choses que l'on possède, finissent par nous posséder"]
--- Log closed Втр Сен 26 00:00:47 2006
