[12:39] <BenC> zedd_: apt-get build-dep linux-source-2.6.15
[11:03] <munzir> Hi, I downloaded http://cdimage.ubuntu.com/dvd/20060411/dapper-dvd-amd64.iso and it gave me a root prompt after this error: kernel direct mapping tables upto ffff810100000000 @ .... can't access tty; job control turned off.
[11:03] <munzir> can I do anything other than downloading another image?
[12:58] <jmg> hi all
[12:58] <jmg> https://launchpad.net/distros/ubuntu/+source/kernel-package/+bug/39948/+index
[12:59] <jmg> straight to the top
[12:59] <jmg> :)
[01:09] <jmg> hi ppd
[01:10] <ppd> hi! If somebody could give me a hint for what package I should file a bug for, I'd be very thankful: Whenever I record TV (bttv -> Leatek Winfast TV2000 XP) via streamer it may happen that the xserver simply restarts oder even the whole system freezes. I got several segfaults in other programs after that. the xserver runs with nvidia. May this be bttv related?
[01:10] <ppd> hi jmg
[01:11] <jmg> ppd: could be, are you using v4l?
[01:11] <jmg> oh bttv... hmm
[01:11] <ppd> I think so
[01:11] <jmg> ppd: probably userspace.. kernel panic?
[01:11] <ppd> overlay mode worked once but doesn't anymore. another mystery
[01:12] <jmg> bizarro
[01:12] <jmg> possibly best to file against nvidia-glx? does it happen with nv?
[01:12] <ppd> that streamer issue?
[01:13] <jmg> yeah
[01:13] <jmg> segfault sounds fun
[01:13] <jmg> any kernel panic/oops?
[01:14] <ppd> panics? no. just either a freeze or a xserver restart
[01:15] <ppd> the whole tv watching/recording thing doesn't work well
[01:15] <jmg> can you sysrq?
[01:15] <jmg> or ssh in form another machine?
[01:15] <jmg> from*
[01:15] <ppd> sysrq?
[01:16] <jmg> magic sysrq key
[01:16] <jmg> sysrq-k 
[01:18] <ppd> ok
[01:18] <ppd> If I get that freeze again I'll use that key combination. But what shall I do if only the xserver restarts?
[01:20] <jmg> read the log output, dmesg
[01:20] <jmg> try and get debugging info from the xserver
[01:21] <jmg> strace output
[01:21] <ppd> ok.
[01:53] <ppd> hi jmg
[01:54] <ppd> I had a complete freeze after having set zapping to overlay mode
[01:55] <ppd> I was completely unable to save the dmesg output
[01:55] <fabbione> ppd: remove nvidia and check if it is still aproblem.
[01:55] <fabbione> a tained kernel with binary drivers is undebuggable
[01:56] <ppd> ok. back in a minute
[01:56] <fabbione> jmg: could you please stop posting bugs in here..?
[01:56] <fabbione> do you know that our kernel-package already had xen?
[01:57] <jmg> fabbione: did you know that it needs to be updated to support 3.0.2? ARCH=xen is no longer a valid target
[01:57] <fabbione> and that the new series in debian (10.X) was almost rewritten from scratch and that what they are doing is readding things from 0?
[01:57] <fabbione> ah ok
[01:57] <jmg> i was afraid of that.
[01:57] <fabbione> well anyway dapper+1 business
[01:57] <jmg> manoj did it for me for etch
[01:57] <jmg> i'll compare his approach with ubuntus
[01:58] <fabbione> it's still a wishlist..
[01:58] <jmg> tbh when i looked at it my first instinct was to rewrite the whole thing in rake
[01:58] <jmg> fabbione nonsense
[01:58] <fabbione> we can't sync kernel-package from Debian
[01:58] <jmg> ill support it myself if i have to
[01:58] <jmg> ok
[01:58] <jmg> thanks
[01:58] <fabbione> kernel-package is specific to the kernel build system
[01:58] <jmg> i know what kernel-package is
[01:58] <fabbione> and we can't rework our build system to just use debian one
[01:59] <jmg> okay
[01:59] <fabbione> so a sync is not doable
[01:59] <fabbione> but
[01:59] <jmg> the xen stuff is doable
[01:59] <fabbione> if you can workout a patch on top our kernel-package
[01:59] <jmg> yeah thats what im looking at tomorrow
[01:59] <fabbione> then it is easier to get it in
[01:59] <jmg> but i hate makefiles
[01:59] <jmg> and i want to rewrite it all to rake
[01:59] <jmg> rather than deal with makefile voodoo
[02:00] <fabbione> have fun with that
[02:00] <jmg> no
[02:00] <jmg> it is a horrible task
[02:00] <jmg> a meaningless task
[02:00] <jmg> makefiles are just such rubbish
[02:00] <jmg> i suppose i could start from scratch though
[02:00] <jmg> :-)
[02:06] <jmg> yay
[02:06] <jmg> ...
[02:08] <zul> heylo
[02:08] <makx> fabbione: you once added an klibc sparc patch patch
[02:09] <makx> he has no desc and no changelog entry
[02:09] <makx> i would like to get it pushed upstream
[02:09] <makx> if you can remember which bug you were hunting that would be great
[02:09] <makx> fabbione: speaking of 03-sparc-fix-paths.diff
[02:09] <makx> in klibc source
[02:10] <ppd> hello again.  nvidia-glx seems to cause my problems
[02:11] <ppd> with nv overlay mode works perfectly and the recordings are far better
[02:11] <ppd> no error so far
[02:11] <jmg> what needs to happen is we need to support a subarch of i386 called xen
[02:11] <jmg> ppd: i knew it, post about it in nvidia forums..
[02:11] <zul> mmmm.....placenta http://www.mirror.co.uk/news/tm_objectid=16958010%26method=full%26siteid=94762%26headline=exclusive--tom-chews-name_page.htm
[02:14] <jmg> make-kpkg --arch i386 --subarch xen
[02:14] <jmg> --arch i386 target is not affected
[02:15] <zul> isnt it a bit late in the release cylce for xen?
[02:15] <jmg> zul: yes but i want to support it seperately when dapper comes out (not in main)
[02:17] <jmg> not even when dapper beta comes out :)
[02:17] <zul> still i dont think there is much you can do about it right now
[02:18] <jmg> zul: not in the main make-kpkg it sounds like :(
[02:18] <jmg> zul: i will provide an alternative to make-kpkg
[02:18] <jmg> zul: since ubuntu-kernel are not willing to support xen at this time
[02:18] <jmg> thanks a
[02:18] <jmg> thanks all*
[02:18] <zul> jmg: knock yourself out
[02:19] <jmg> zul: converting the makefiles to rake seems like a good waste of time to me
[02:19] <jmg> zul: and a pointless rdepend of rake sounds like fun too
[03:02] <jmg> http://arch.debian.org/cgi-bin/archzoom.cgi/srivasta@debian.org--etch/kernel-package--devel--9.0--patch-143?log
[03:43] <fabbione> makx: i don't remember.. let me check
[03:46] <fabbione> makx: oh that one.. man dude... if you need an explanation for that one...
[03:46] <fabbione> but yes.. it should go upstream
[03:46] <fabbione> assuming new upstream still need it
[06:00] <fabbione> BenC: what can we do to help you hunting down #34065 ?
[06:02] <BenC> fabbione: I need some sort of scsiparm or smart output on these things so I can see what I am looking for
[06:02] <fabbione> BenC: sure...
[06:03] <fabbione> tell me exactly what cmd line you want 
[06:03] <fabbione> or otherwise send me your ssh key :)
[06:04] <makx> fabbione: yeah bash me :-P
[06:04] <makx> ;)
[06:04] <BenC> hdparm -I /dev/sda > hdparm.txt
[06:06] <BenC> Also: hdaparm -C /dev/sda
[06:08] <BenC> Also, see if "hdparm -S 0 /dev/sda" disables the spindown
[06:08] <fabbione> BenC: people.u.c/~fabbione/hdparm.txt and hdparm2.txt
[06:08] <fabbione> yes i can try that too
[06:09] <fabbione>  setting standby to 0 (off)
[06:09] <fabbione> and disks did spin up again
[06:09] <fabbione> i will be able to see if they stop again later
[06:09] <BenC> your sda is in standby mode
[06:09] <BenC> and hdh is active/idle
[06:10] <BenC> standby may be a default mode
[06:10] <BenC> this may require that the ubuntu-server metapackage (or whatever it is) sets -S 0 for all drives
[06:11] <fabbione> hdh is not idle because i am downloading stuff on it :)
[06:11] <fabbione> and we need to get this fixed n the kernel
[06:11] <BenC> makes sense :)
[06:11] <fabbione> it's a regression from .12 
[06:12] <fabbione> i can't even think of how much time it would take to my system to boot if i had to issue hdparm -S 0 /dev/ for the 34 scsi disks in the SAN
[06:12] <fabbione> because i got a SAN up and running..
[06:12] <zul> a couple of minutes :)
[06:13] <Mithrandir> you can probably do that in parallell though?
[06:13] <fabbione> well we know what's the IOCTL
[06:13] <fabbione> can't we just check why the default has been changed in the kernel? or why it did start spinning down all of a sudden?
[06:14] <fabbione> Mithrandir: yes but come on.. 
[06:14] <fabbione> what about hotplugged devices
[06:14] <fabbione> this has to be something more dinamyc than just boot
[06:14] <BenC> fabbione: One thing you can test is -21, since it pulled in some libata-acpi stuff that might help with this
[06:15] <BenC> does it only affect sata?
[06:15] <fabbione> nope also normal ATA
[06:15] <Mithrandir> fabbione: udev rule, then
[06:15] <fabbione> it's kind of scary to hear a raid5 spinning down and up
[06:15] <BenC> fabbione: doing it at boot wont take that long since all the disks will be spun up already
[06:15] <BenC> guessing it will take all of 5 seconds at most
[06:16] <fabbione> why don't we just fix where it should be fixed? :)
[06:16] <fabbione> also
[06:16] <fabbione> there is one major thing
[06:16] <fabbione> how do we tell the boot that it is a server install?
[06:16] <fabbione> or server boot?
[06:17] <fabbione> such a change will go into desktop too
[06:17] <BenC> isn't there a -server metapackage?
[06:17] <fabbione> nope
[06:17] <fabbione> there is no need of one
[06:17] <BenC> there should be :P
[06:37] <zul> Yippe Skippe... https://lists.ubuntu.com/archives/dapper-changes/2006-April/009446.html
[06:43] <infinity> zul: Is that your first upload to the archive?
[06:43] <zul> yep..
[06:43] <infinity> Congrats.
[06:43] <zul> thanks..
[06:43] <zul> you love me you really love me ;)
[06:44] <fabbione> zul: now... move your bottom on -motu and starts to fix universe instead of pretending to be a kernel hacker. kthxbye.
[06:44] <zul> :P
[06:45] <zul> yes mommy
[07:03] <fabbione> makx: i was just waiting for hpa to show up on irc :)
[07:03] <fabbione> but that will do too
[07:04] <makx> fabbione: ok thx, sorry have no idea about those sparc assembly so my desc was stumble-stumble
[07:04] <fabbione> makx: it's fine. it's nothing to do with sparc asm.. just Kbuild that required a kick
[07:05] <makx> fabbione: yup, looked like not building it. :)
[07:19] <ath> hi everyone
[07:19] <ath> i'm asking for some help in resolving a kernel bug in dapper
[07:20] <ath> malone bug 31527
[07:22] <ath> it affects the kernel side of DRI and it results in a complete system crash
[07:23] <ath> a vanilla 2.6.15 works fine
[07:24] <makx> fabbione: sam has a better fix, i would appreciate if you give it a build shot, otherwise i just push into the next debian upload
[07:32] <fabbione> makx: i just powered down all the sparcs for the evening
[07:34] <fabbione> makx: well he is also commenting on the chmod that's not coming from our patches...
[07:34] <fabbione> but yeah i can give it a shot
[07:35] <ath> well, thanks anyway
[08:48] <makx> fabbione: yes he reworked the sparc/Makefile.inc
[08:48] <fabbione> yes i saw the patch
[08:49] <makx> patch will not apply to unstable klibc due to s/ARCH/KLIBCARCH/
[08:54] <fabbione> yes i need to test it on git
[10:41] <allen> Would this be the proper place to ask a question regarding the latest kernel on amd64. 2.6.15-19-amd-k8 worked fine for me but my system doesn't boot with 2.6.15-20-amd64-k8. 
[10:42] <allen> I've been running Dapper for a while and it seems every 2nd or 3rd kernel doesn't boot on my system, I end up running an older version until a newer one starts working.
[10:52] <mjg59> BenC: We still don't seem to have the 3945 driver?
[11:00] <BenC> mjg59: working on it right now
[11:10] <mjg59> BenC: Rocking
[11:59] <BenC> ok, ipw3945 is in git now