=== bronson [n=bronson@adsl-75-36-145-166.dsl.pltn13.sbcglobal.net]  has joined #ubuntu-kernel
=== __keybuk [n=scott@169.222.10.235]  has joined #ubuntu-kernel
=== bronson_ [n=bronson@c-24-5-71-119.hsd1.ca.comcast.net]  has joined #ubuntu-kernel
=== bronson_ [n=bronson@adsl-75-36-145-166.dsl.pltn13.sbcglobal.net]  has joined #ubuntu-kernel
=== __keybuk [n=scott@169.222.10.235]  has joined #ubuntu-kernel
=== lifeless [n=robertc@ppp245-86.static.internode.on.net]  has joined #ubuntu-kernel
=== doko [n=doko@dslb-088-073-082-079.pools.arcor-ip.net]  has joined #ubuntu-kernel
=== kkubasik [n=kjk38@kjk38-laptop.STUDENT.CWRU.Edu]  has joined #ubuntu-kernel
=== rikai_ [n=rikai@unaffiliated/rikai]  has joined #ubuntu-kernel
=== zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com]  has joined #ubuntu-kernel
=== tuxmaniac [n=aanjhan@unaffiliated/tuxmaniac]  has joined #ubuntu-kernel
=== Keybuk [n=scott@169.222.10.235]  has joined #ubuntu-kernel
=== sevrin [n=sevrin@202.75.186.154]  has joined #ubuntu-kernel
=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-kernel
=== johanbr [n=j@blk-137-114-65.eastlink.ca]  has joined #ubuntu-kernel
[06:18] <fabbione> morning
=== Keybuk [n=scott@169.222.10.235]  has joined #ubuntu-kernel
=== Starting logfile irclogs/ubuntu-kernel.log
=== ubuntulog [i=ubuntulo@ubuntu/bot/ubuntulog]  has joined #ubuntu-kernel
=== Topic for #ubuntu-kernel: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel | 2.6.20-5.7 uploaded - Things are getting solid now. Use it, but there are still a few missing modules.
=== Topic (#ubuntu-kernel): set by BenC at Sat Jan  6 08:06:31 2007
=== datten_ is now known as datten
=== infinity_ [n=adconrad@cerberus.0c3.net]  has joined #ubuntu-kernel
=== Lure [n=lure@external-7.hermes.si]  has joined #ubuntu-kernel
=== bronson_ [n=bronson@adsl-75-36-145-166.dsl.pltn13.sbcglobal.net]  has joined #ubuntu-kernel
=== Lure [n=lure@external-7.hermes.si]  has joined #ubuntu-kernel
=== calavera [n=calavera@195.Red-80-26-32.staticIP.rima-tde.net]  has joined #ubuntu-kernel
=== fs [i=fs@213.178.77.98]  has joined #ubuntu-kernel
=== ivoks [n=ivoks@backup.grad.hr]  has joined #ubuntu-kernel
=== infinity3 [n=adconrad@cerberus.0c3.net]  has joined #ubuntu-kernel
[11:59] <jes-o-mat> kylem: your changes made it into git - thnx
[12:02] <jes-o-mat> now I'm just wondering how to compile your tree
=== ivoks [n=ivoks@backup.grad.hr]  has joined #ubuntu-kernel
[12:18] <jes-o-mat> a lot of files are missing in the debian/ directory
=== Lure [n=lure@external-7.hermes.si]  has joined #ubuntu-kernel
=== infinity_ [n=adconrad@cerberus.0c3.net]  has joined #ubuntu-kernel
[12:22] <jes-o-mat> BenC: maybe you know some points that will get me further?
=== infinity4 [n=adconrad@cerberus.0c3.net]  has joined #ubuntu-kernel
[12:50] <\sh> which script generates the initrd for the linux-image package in postinstall? I don't see it in debian/* of linux-source-*, could be that I'm blind ;)
[12:54] <Mithrandir> kernel-package
[12:58] <\sh> yes...I see it now ;) make-kpkg generates postinst
[01:51] <cjwatson> BenC: https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/76341 is quite a nasty issue. Do you think you/kyle could have a look at it with the lkml reference I gave?
=== ivoks [n=ivoks@backup.grad.hr]  has joined #ubuntu-kernel
[02:17] <BenC> cjwatson: sure
[02:17] <BenC> cjwatson: Ah, I talked to Keybuk about this, and I'm not sure we've concluded whether it was a udev or a kernel bug
[02:17] <BenC> the kernel code hasn't changed
[02:18] <cjwatson> the lkml thread seemed to reckon that it was a kernel bug due to MODALIAS=i82365
[02:19] <cjwatson> but I couldn't find anything outside that thread
[02:19] <cjwatson> I tried to work around it in udev rules, but haven't succeeded yet
=== zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com]  has joined #ubuntu-kernel
[02:38] <jes-o-mat> BenC: no idea regarding my problem?
=== ivoks [n=ivoks@backup.grad.hr]  has joined #ubuntu-kernel
[02:40] <BenC> jes-o-mat: The URL in the topic has a link to compiling custom kernels
[02:41] <zul> hey
[02:41] <jes-o-mat> BenC: yes and I was using the commands as written
[02:42] <BenC> jes-o-mat: Without some context, I can't give you any more info
[02:42] <jes-o-mat> but there are a lot files missing in kylem's git tree
[02:42] <BenC> Like what files
[02:43] <jes-o-mat> basic things like copyright e.g.
[02:43] <BenC> what git tree are you using?
[02:44] <jes-o-mat> I have taken some of them from the linux-source package, but now I got to a point where the build scripts needs some debian/d-i/shared/firmware/* files which are not present
[02:44] <jes-o-mat> ubuntu-dapper-updates.git
[02:44] <jes-o-mat> from kyle
[02:44] <BenC> on kernel.org?
[02:45] <jes-o-mat> yes
[02:45] <jes-o-mat> http://www.kernel.org/git/linux/kernel/git/kyle/ubuntu-dapper-updates.git
[02:45] <jes-o-mat> I fetched it as supposed via rsync
[02:46] <BenC> I get 404 on that url
[02:47] <jes-o-mat> Generating......
[02:48] <jes-o-mat> http://www.kernel.org/git/?p=linux/kernel/git/kyle/ubuntu-dapper-updates.git;a=summary
[02:48] <jes-o-mat> sorry
[02:49] <jes-o-mat> mixed up http and rsync url's a bit
[02:49] <BenC> http://www.kernel.org/git/?p=linux/kernel/git/kyle/ubuntu-dapper-updates.git;a=tree;f=debian;h=1690c1d0bf1d38ebd708df29599ae4195871d490;hb=HEAD
[02:49] <BenC> shows the copyright file, and others
[02:49] <BenC> must be your lock tree
[02:50] <BenC> s/lock/local/
[02:51] <jes-o-mat> I used the following to fetch the tree:  git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/kyle/ubuntu-dapper-updates.git ubuntu-dapper-updates
[02:55] <BenC> All I know is, the tree on kernel.org is fine...not sure why yours is having problems
[02:55] <BenC> git-checkout -f
[02:55] <BenC> see if that helps
[02:56] <jes-o-mat> ini get a lot of "unable to read sha1 file of ..."
[02:56] <jes-o-mat> maybe the argument "ubuntu-dapper-updates
[02:56] <jes-o-mat> " is false
[02:56] <jes-o-mat> I just guessed it
[02:57] <jes-o-mat> cuase the wiki is only talking about linux-2.6
[02:57] <jes-o-mat> oh
[02:57] <jes-o-mat> that's for the local directory :)
[02:59] <BenC> jes-o-mat: my guess is that git isn't following the alternative objects to my tree
[02:59] <BenC> jes-o-mat: Best bet is to clone my tree, then pull from kyle's
[02:59] <kylem> it probably doesn't if you use rsync.
[02:59] <kylem> use git://
[03:00] <BenC> jes-o-mat: Telling me about the missing sha1 messages would have been helpful before :)
[03:03] <jes-o-mat> BenC, kylem: I'll try using git://
[03:03] <jes-o-mat> BenC: the list was *very* long :)
[03:04] <kylem> jes-o-mat, my repository shares objects with ben's so that it doesn't take a long time to mirror. the downside is you need to use a git-aware protocol for fetching it.
[03:04] <jes-o-mat> kylem: is the host still rsync.kernel.org?
[03:05] <jes-o-mat> or is there some git.k.o host?
[03:05] <kylem> it's the same pair of machines either way
[03:05] <kylem> a CNAME by any other name would resolve as sweet.
[03:06] <tepsipakki> kylem: I see the upload to dapper-proposed as rejected?
[03:06] <jes-o-mat> sweet CNAME ... I need to remember that :)
[03:06] <kylem> tepsipakki, one of them was rejected, there were two.
[03:08] <tepsipakki> kylem: should it be built by now and available on a.u.c?
=== ivoks [n=ivoks@backup.grad.hr]  has joined #ubuntu-kernel
=== infinity_ [n=adconrad@cerberus.0c3.net]  has joined #ubuntu-kernel
[03:09] <kylem> tepsipakki, i'd have thought so, i'm new to this whole game though so i'm not really sure what the process is once i upoad.
[03:10] <tepsipakki> kylem: I've searched the dapper queues and I can see only the rejected one :)
[03:10] <kylem> possibly one of the archive folks needs to be cattle proded.
[03:11] <tepsipakki> heh
[03:15] <jes-o-mat> *grml* git:// is blocked by firewall
[03:16] <Mithrandir> jes-o-mat: ssh -D 1234 wherever, then use tsocks on localhost:1234
[03:17] <Mithrandir> ssh -D is like the best invention since the internet.
[03:19] <jes-o-mat> Mithrandir: great! didn't knew the -D flag - I always had used -L or -R
[03:19] <kylem> Mithrandir, hah.
[03:19] <zul> i thought slice bread was a pretty good invention myself
[03:21] <Mithrandir> sliced bread is a _horrible_ invention.
[03:24] <zul> i disagree
[03:27] <kylem> i hate sliced bread.
[03:28] <kylem> i much prefer carving out a quadrant of a nice big loaf of pumpernickle
[03:30] <thom> i am lazy. all dutch bread is horrific, so it makes no odds to me
[03:30] <jes-o-mat> hrhr
[03:30] <Mithrandir> thom: make it yourself and you can have it however you want.
[03:31] <thom> Mithrandir: see my leading sentence
[03:31] <Mithrandir> thom: bread making machine.
[03:31] <Mithrandir> pour ingredients, set timer, wake up to a fresh loaf of bread.
[03:31] <thom> had one, hardly ever used it
[03:33] <zul> heh if i cook something there is a pretty good chance that it will implode or explode
=== pmjdebruijn [n=pmjdebru@pmjdebruijn.xs4all.nl]  has joined #ubuntu-kernel
=== tuxmaniac [n=aanjhan@unaffiliated/tuxmaniac]  has joined #ubuntu-kernel
[04:49] <jes-o-mat> kylem: seem that the changes does not solve #37452 :/
[04:50] <jes-o-mat> everything compiled well but after creating the hw-raid the kernel cannot access sda
[04:52] <kylem> well, someone who actually has the hw will have to hunt down the changeset which fixes it. i can't test it.
[05:02] <cjwatson> BenC: did /proc/cpuinfo change on i386/amd64 recently (.20) for multiprocessor machines? I see why bug 79109 is happening, but apparently it didn't happen with Herd 1 and the relevant code in base-installer hasn't changed at all
[05:02] <BenC> bug #79109
[05:03] <BenC> cjwatson: It's possible, what portion is it using?
[05:05] <BenC> cjwatson: diff'ing the cpuinfo from my 2.6.20 coreduo and 2.6.17 core2duo doesn't show anything changing other than values of the cpu itself
[05:06] <BenC> I can try a boot into 2.6.20 for the core2duo and see about same cpu changes
[05:14] <BenC> cjwatson: The only thing I see different is that in 2.6.20 it recognizes the difference between physical cpu's and cores
[05:15] <BenC> so on .17 it would show physical_id={0,1} and core_id=0 for the two, and on .20 it shows physical_id=0 and core_id={0,1}
[05:15] <cjwatson> BenC: it's grepping for 'cpu family' lines, and forgot to do head -n1
[05:16] <cjwatson> BenC: if older kernels had only one cpu family line, but current ones have two (which current ones do), then that would explain it
[05:17] <BenC> I show two lines in both
[05:17] <BenC> so that didn't change
[05:17] <BenC> does it use siblings?
[05:18] <BenC> or "cpu cores"?
[05:18] <cjwatson>         FAMILY=`grep '^cpu family' "$CPUINFO" | cut -d: -f2`
[05:18] <cjwatson>         case "$VENDOR" in
[05:18] <cjwatson>                 " AuthenticAMD"*)
[05:18] <cjwatson>                         case "$FAMILY" in
[05:18] <cjwatson>                                 " 6"|" 15")     echo k7 ;;
[05:18] <cjwatson> just that sort of thing
[05:19] <cjwatson> dunno, maybe it was always broken - I was just curious
[05:19] <cjwatson> oh, unless vendor_id changed similarly - it greps for that too
[05:20] <cjwatson> nothing else, not siblings or cpu cores
[05:20] <BenC> still shows GenuineIntel
[05:21] <BenC> On i386 and amd64 there shouldn't any of this anyway
[05:21] <BenC> it should always install -generic
[05:22] <cjwatson> -generic is built for 586, so it's needed for 486 systems
[05:22] <cjwatson> most of the code is inherited, but still
[05:23] <BenC> true, -386 is the side case
[05:23] <cjwatson> on amd64, in practice it makes no difference - it installs -generic regardless
[05:23] <cjwatson> it's not vendor_id contents I'm thinking about, but whether it appears once or twice
[05:23] <jes-o-mat> kylem: I just digged into the source and the suggested patchset from Cedric Schieli did not made it into your git
[05:24] <BenC> it appears twice on .17 and .20
[05:24] <cjwatson> anyhow, I have a fix now
[05:24] <cjwatson> ok, thanks
[05:24] <BenC> cjwatson: Do you want my cpuinfo's for reference?
[05:25] <BenC> cjwatson: emailed, can't hurt to have it
[05:27] <cjwatson> sure, thanks
[05:38] <cjwatson> BenC: ah, fjp pointed me in the direction of the answer - between Herd 1 and 2, we switched the installer from 386 to generic, and 386 doesn't have SMP alt so the second core didn't show up in cpuinfo
[05:42] <kylem> jes-o-mat, which kernel image do you need?
[05:43] <jes-o-mat> kylem: -server
[05:43] <kylem> amd64 or i386?
[05:44] <jes-o-mat> i386 (for now)
[05:45] <kylem> alright
=== kkubasik [n=kjk38@kjk38-laptop.STUDENT.CWRU.Edu]  has left #ubuntu-kernel [] 
[05:53] <BenC> cjwatson: The d-i installer, or the livecd installer?
[05:53] <BenC> I thought the installer for the alt CD was going to remain 386
[05:54] <cjwatson> for edgy, it did, but I elected to change that for feisty and just retain the netboot install as 386
[05:54] <cjwatson> I think I mentioned that possibility in mail to you pre-edgy
[05:55] <cjwatson> it simplifies the desktop seed rather a lot, because we can just slam linux-headers-generic in there and not worry about which installer is in use
[05:55] <BenC> so the bug was always there, it just never showed up because the -386 installer didn't see the extra cpu's?
[05:55] <cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel/2006-December/023036.html
[05:55] <cjwatson> right
[05:55] <cjwatson> I should probably have CCed you on that mail about the installer change
[05:57] <BenC> well, the cpu checking is still pretty moot, because if they boot the live or alt cd's, they don't need -386 anyway
[05:57] <BenC> but it certainly can't hurt to have it, since the end result is the same :)
[05:58] <cjwatson> that's true, but the same code is used for the netboot installer where it might conceivably matter
[05:59] <cjwatson> I realise it's all a tiny corner case - I just prefer fixing mostly-working code over removing it :)
=== pmjdebruijn [n=pmjdebru@pmjdebruijn.xs4all.nl]  has joined #ubuntu-kernel
=== holycow [n=a@mail.wjsgroup.com]  has joined #ubuntu-kernel
=== TheMuso [n=luke@ubuntu/member/themuso]  has joined #ubuntu-kernel
=== datten_ [n=datten@xdsl-84-44-195-11.netcologne.de]  has joined #ubuntu-kernel
=== datten_ is now known as datten
=== cassidy [n=cassidy@host-213-189-171-21.brutele.be]  has joined #ubuntu-kernel
=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-kernel
=== johanbr [n=j@JBrannlund.MathStat.Dal.Ca]  has joined #ubuntu-kernel
=== cassidy [n=cassidy@host-213-189-171-21.brutele.be]  has joined #ubuntu-kernel
=== pmjdebruijn [n=pmjdebru@pmjdebruijn.xs4all.nl]  has joined #ubuntu-kernel
=== Lure [n=lure@clj46-234.dial-up.arnes.si]  has joined #ubuntu-kernel
=== ivoks [n=ivoks@17-81.dsl.iskon.hr]  has joined #ubuntu-kernel
=== Red_Herring|ugh [n=rj@c-67-162-70-40.hsd1.il.comcast.net]  has joined #ubuntu-kernel
[10:30] <Red_Herring|ugh> yo
[10:30] <Red_Herring|ugh> anyone around?
[10:32] <Red_Herring|ugh> guess not.
[10:32] <Red_Herring|ugh> anyways ill ramble on about my problems
[10:32] <Red_Herring|ugh> so i got an edgy amd64 kubuntu install
[10:32] <Red_Herring|ugh> and one day
[10:33] <Red_Herring|ugh> i boot up
[10:33] <Red_Herring|ugh> and get a kernel panic
[10:33] <Red_Herring|ugh> the "Aiee, killing interrupt handler!" kind
[10:33] <Red_Herring|ugh> so i boot from livecd
[10:33] <Red_Herring|ugh> chroot in
[10:33] <Red_Herring|ugh> recompile the kernel
[10:33] <Red_Herring|ugh> and boot again
[10:34] <Red_Herring|ugh> and it complains about missing modules
[10:34] <Red_Herring|ugh> so
[10:34] <Red_Herring|ugh> im runnin a livecd now
[10:34] <Red_Herring|ugh> chrooted into the thing
[10:35] <Red_Herring|ugh> and am wondering
[10:35] <Red_Herring|ugh> whats the best solution
[10:35] <Red_Herring|ugh> i'd really hate to install
[10:35] <ivoks> make modules_install ?
[10:35] <Red_Herring|ugh> ?
[10:35] <ivoks> but this is development channel, not support
[10:36] <Red_Herring|ugh> ok
[10:37] <Red_Herring|ugh> but can you at least tell me how to diagnose it?
[10:44] <Red_Herring|ugh> ... thanks
=== Keybuk [n=scott@169.222.10.235]  has joined #ubuntu-kernel
=== zul_ [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com]  has joined #ubuntu-kernel
=== johanbr [n=j@JBrannlund.MathStat.Dal.Ca]  has joined #ubuntu-kernel