[12:04] and it uses rdtsc(), so it's x86 only [12:04] mjg59: any idea what a good portable replacement is for rdtsc()? [12:05] and when it says "work with current 802.11 stack", it means that in the loosest way [12:05] it's still using local ieee80211 headers, and abusing the real stack [12:06] BenC: What fun [12:07] I'm not sure about including it...my biggest fear is that I'll become so frustrated with it that I'll end up getting an 8180 card and rewrite the whole driver [12:07] What's it actually using rdtsc for? [12:07] Ha [12:07] mjg59: filling in some hosttime in a struct [12:08] Does it look important, or does it just need a monotonic timer? [12:08] mjg59: don't laugh, that's how I ended up taking over the ieee1394 stack :) === rtcm_ [n=jman@81.84.150.197] has joined #ubuntu-kernel [12:08] Oh dear [12:08] it's something to do with a prism header [12:09] Nngh. [12:10] BenC: It only seems to be for monitor mode [12:14] BenC: Other code just seems to use jiffies [12:14] it has it commented out to use jiffies near the top of that function [12:14] guess I'll do that aswell [12:14] I'd just go back to that, TBH [12:14] It seems to be a fairly standard 802.11 thing [12:15] wait, that's mac_time [12:15] oh well, I can use it still [12:16] If you dig for hosttime in drivers/net/wireless, there's no shortage of hits [03:39] sweet === BenC discovers git-bisect [03:39] that is the most awesome tool and makes git totally worth using, even if it was the crappiest scm in the world === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel === _native_ [n=alpha@cpe-66-87-4-181.ut.sprintbbd.net] has joined #ubuntu-kernel === _native_ [n=alpha@cpe-66-87-4-181.ut.sprintbbd.net] has left #ubuntu-kernel ["cabal] [07:52] benc: would be nice if it could be automated. === chmj [n=chmj@wbs-146-184-221.telkomadsl.co.za] has joined #ubuntu-kernel === CataEnry [n=cataenry@host204-30.pool8248.interbusiness.it] has joined #ubuntu-kernel [11:58] hi all [12:17] cya === michel [n=michel@zux006-048-229.adsl.green.ch] has joined #ubuntu-kernel [12:23] i want to patch ltsp-kernel of ubuntu, howto? === jane_ [n=JaneW@wbs-146-151-44.telkomadsl.co.za] has joined #ubuntu-kernel === Alhica [n=Torresm@a81-84-252-5.cpe.netcabo.pt] has joined #ubuntu-kernel === Alhica [n=Torresm@a81-84-252-5.cpe.netcabo.pt] has left #ubuntu-kernel [] [01:50] BenC: is it possible to do firewire back to back? [01:51] between 2 controllers i mean [01:51] if so do i need a special cable or something? === chmj_ [n=chmj@wbs-146-161-75.telkomadsl.co.za] has joined #ubuntu-kernel === CataEnry [n=cataenry@host204-30.pool8248.interbusiness.it] has joined #ubuntu-kernel [01:57] hi all [01:58] fabbione: yeah [01:58] just a normal cable [01:59] think of firewire as a network where any device with more than one port is like a hub :) [02:00] I've had a winxp, macosx, 2 linux boxes, 3 firewire storage devices, firewire camera, all connected on a bus together [02:00] using IPover1394 between the winxp/macosx/linux boxes too [02:00] ah cool [02:00] ok [02:00] i only have 2 boxes [02:00] nothing fancy [02:01] curious to try it [02:01] probably more [02:01] how fast can it go? [02:02] ~400 Mbps, in theory. [02:02] that would be a cheap way to upgrade my 100Mb LAN to a ~ 400Mb [02:02] or buy a gigabit switch [02:02] fabbione: Do you actually have any disks that can push data that fast? [02:02] but the latter is hutterly expensive [02:03] jbailey: yes [02:03] Handy. =) [02:03] fabbione: the linux IPover1394 isn't all that stable [02:03] BenC: well.. it's a good way to push you to fix it :P [02:03] fabbione: not my driver :P [02:04] still your kernel ;) [02:04] I just did the initial ethernet-over-1394, the RFC stuff came from someone else [02:04] the ethernet-over-1394 was really stable, since it was just a firewire packet wrapped around a normal ethernet packet [02:04] but it was linux-only [02:05] yeah i could guess so [02:05] i guess i will switch to GigaEthernet [02:05] build a 1394 network as backup [02:05] and use the 100Mb for management [02:05] or something like that [02:05] get some S800 firewire cards, and you'll almost be gigabit :) [02:06] BenC: i have the cards.. i need the switch [02:06] and a good switch is $$$ [02:06] hey there [02:06] quick question [02:06] hey kiko [02:07] what's the difference between linux-image-2.6.10-6-686-smp and linux-image-2.6.10-5-686-smp? [02:07] kiko: about 4 revisions :) [02:07] AHAHAHHAHA [02:08] really? [02:08] kiko: you'll need to be more specific than -6 and -5, since it could be -5.10 and -6.99 [02:08] oh. those are just the package names [02:08] kiko: the functional difference is from -5 to -6, the kernel ABI changes [02:08] ii linux-image-2.6.10-5-686-smp 2.6.10-34.7 [02:09] that's what we have installed [02:09] oh, I don't know how the revisions worked back then, I only know the current convention for breezy/dapper [02:10] hum hum [02:10] Bisecting: 2 revisions left to test after this === BenC loves git-bisect [02:11] do you have vmware? [02:12] yes, but not installed right now [02:12] we use vmware 5's snapshots for that kind of iteration testing. 'tis wonderful. [02:13] BenC: it's the same convention [02:13] kiko: it's an ABI change [02:13] you install the new one.. boot in the new one.. you are done [02:13] fabbione: I know the ABI bump is, but the 34.7 thing isn't :) [02:13] oh right [02:13] yes [02:13] we did add the ABI number to the debian version only in breezy [02:13] Earthpig: for testing kernel regressions? [02:13] the old pkgs have standard numbers [02:14] fabbione, should I be using the newer kernel or does it not really matter? [02:14] by newer kernel I mean newer-ABI-kernel [02:14] kiko: well it's a security update that covers no less than 10 vulnerabilities [02:14] kiko: it's up to you [02:14] i suggest to use the new one [02:14] oh [02:14] so the -5 kernel was not updated? [02:15] ah. I think I understand the problem [02:15] I shouldn't have installed the -X kernel explicitly, right? [02:15] benc: well, we don't do kernels, so no. :) [02:15] kiko: the security update forced a bump to -6 [02:15] I see [02:15] that's okay [02:15] so it won't automatically update? [02:15] (i.e. JRU does an apt-get update apt-get dist-upgrade and no new kernel) [02:15] not unless you have linux-image-686-smp installed [02:15] the meta-packages should pull in the upgrades [02:15] yeah, that's what I should have. [02:16] which is the default [02:16] benc: we do use it for automated testing of nightlies though. [02:16] Earthpig: cool [02:16] fabbione: I think -4.4 is going to go out today [02:17] after which I will attempt to get l-r-m built against 2.6.15, and then go for linux-meta [02:17] BenC : Please don't. [02:17] BenC : l-r-m will be unuseably broken as soon as the new X finally builds (which will happen in the next day, it looks like), so I need to do more than just "make it build" anyway. [02:17] infinity: when's your next planned upload of l-r-m? [02:18] BenC: ok.. but it's pointless to upload until the gcj thing is sorted [02:18] BenC: basically all the archive is unbuildable atm === BenC sighs [02:18] BenC: plus infinity loves to spank l-r-m :) [02:18] BenC : I'll make l-r-m a priority tomorrow, since I expect to see X build tonight. [02:18] you people enjoy dashing my hopes don't you? :) [02:19] infinity: ok, I'll leave it alone, and just get linux-meta ready for when things settle down [02:20] I'd like to see CDs built with shiny new kernels too, so I'm on your side. Don't worry. :) [02:20] Speaking of CDs, I really need to test that 640x400 vga16fb patch and get you to include it ASAP. [02:20] BenC: Kamion wants to coordinate with you some udeb reorganization stuff [02:21] Certainly before we do the next flight CD anyway. [02:22] fabbione: yeah, I'm in #ubuntu-boot, but so far, I don't know what coordination I need to do [02:22] I was under the impression that once I got the kernel uploaded, the rest was on him :) [02:22] BenC: basically Kamion wants to revert a few changes in the amount of udebs we do build [02:22] BenC: yeah well.. he might need your help to setup git and stuff [02:22] infinity: yeah, I can test that on atleast one system where I know vga16 has always been broken [02:22] he knows what needs to touch [02:22] BenC : Note that Kamion/Keybuk would really rather not see linux-meta updated until we're sure the udev stuff is sorted. [02:23] BenC : You have such a system?... ROCK THE FUCK ON. I've been resigned to doing this blind until now. :) [02:23] infinity: it's an ATI card connected to a TV via svideo, so it's not the normal brokeness, but it is broken [02:23] I've been using vesa happily [02:24] fabbione: ok [02:24] translating infinity to a more common language: "Dear Ben, given your card is broken, you win! FIX IT! kthxbye!" [02:25] lol [02:25] BenC : Hrm, not sure if this fix will fix your case, but bonus if it does. [02:26] infinity: I have a couple of vgacon "fixes" from -mm that I want to test too...not going into our kernel yet, but I'll let you know [02:27] rather wait for your patch before I touch vgacon at all [02:27] hrmm...not sure if I need to mark that last boot as git-bisect bad, or good [02:28] it booted way past where it normally crashed, but it got a segv in the initrd, and couldn't mount the rootdev [02:29] BenC : My patch should just be touching the size/timings struct, if you're mucking with stuff outside that, we won't conflict. [02:29] BenC : I just need to pick the "right" timings, and test the fuck out of them before I go blowing up people's hardware. === rtcm [n=jman@81.84.150.197] has joined #ubuntu-kernel === sivang [i=sivan@ubuntu/member/sivang] has joined #ubuntu-kernel [02:48] BenC: Hey Ben, 'sup? I installed 2.6.15 and am now getting "BUG: Soft lockup on CPU#0" [02:48] BenC: anything I can help to sovle this, or do more testing for you? [02:49] sivang: backtrace or oops of any kind? [02:49] BenC: if logs were not rotated, I should be able to give those . let's see [02:51] BenC: re: oops, machine can't boot past it. not even in "rescue" mode [02:53] BenC: can't seem to find it in the syslog, where else should I be looking? [02:53] dmesg [02:53] when it happens, does the machine lockup? === CataEnry [n=cataenry@host204-30.pool8248.interbusiness.it] has joined #ubuntu-kernel [02:53] BenC: yes sir :) [02:54] re === spike [n=spike@unaffiliated/spike] has joined #ubuntu-kernel [03:01] hi there [03:03] sivang: does Alt+SysRQ work? [03:03] I was trying to get myself acquainted with dapper and thinking of kernel specs for dapper and ubuntu-server [03:04] is selinux/grsec integration planned? [03:04] and what about ELSA/CSA patches? [03:04] or this sort of questions are welcome here? [03:05] arent* [03:07] BenC: I will have to try. also, I can't seem to find the dmesg logs for that hangup [03:07] BenC: any tips on that? [03:07] BenC: (this all mean boot cycles for me) [03:08] sivang: if it was a lockup, it wont be there [03:08] you'll need to do a alt+sysrq, and either hand write the trace, or take a photo of it and email that too me [03:09] BenC: ok, I will give it a try. [03:09] I'll be bak ;-) [03:32] BenC: now it locked up, on the corrupted USPlash screen , Alt+SysRq does nothing [03:33] sivang : If you boot without "splash" you can avoid usplash. [03:33] sivang : You might at least get some better debugging output then. [03:34] sivang : And take away "quiet" from the command line too, if you want a bit more verbosity about where it might be dying. [03:34] infinity: eh right, dumb me, not like I don't know that. (I used to do that when bootsplash just entered, since I am used to see text messages and bootsplash was bit uncomfortable. [03:34] infinity: anyway, yet-another-boot-cycle [03:41] ok, couldn't see the "Soft lock" anymore [03:42] but I did see where it halted, again SysRq helped me none [03:43] [17179589.808000] Intel ISA PCIC probe: not found. Before that I got "* /etc/network/options is deprecated" === rtcm_ [n=jman@81.84.150.197] has joined #ubuntu-kernel === JaneW [n=JaneW@wbs-146-151-44.telkomadsl.co.za] has joined #ubuntu-kernel [03:57] BenC: any idea? [03:57] did alt+sysrq work? [03:57] ok, I see, no [04:06] brb [04:08] sivang: I'm at a loss, try booting with "noapic", "nolapic", etc, to see if that changes anything === CataEnry [n=Enrico@host204-30.pool8248.interbusiness.it] has joined #ubuntu-kernel [04:10] BenC: ok, will do. Why isn't anything on the kernel that will open and close a log file in an atomic manner, that way if something wrong happens, we would always be able to see the logs? [04:12] sivang: at that point, the system dies, and likely is so trahed that opening a file would be disastrous [04:18] BenC: I see. What about doing that before it dies, or is there no possible sane way to know that before it acutally dies ? :) [04:19] it could die before even being able to access the disk [04:19] ah right [04:19] darn [04:19] oh well, I will try again in a sec [04:20] BenC: btw, what nolapic does? [04:20] No Local APIC [04:20] k, thx [04:20] which kernel are you using anyway, -386, -686, -k7? [04:22] BenC: 686, the smp and UP enabled [04:22] try doing "smp2up=off" aswell then [04:22] /boot/vmlinuz-2.6.15-3-686 [04:23] and that tells it to? [04:23] are you on an SMP machine? [04:24] yes [04:24] then it wont do anything, so don't worry about it :) [04:27] BenC: there a way to know for sure if you're on an SMP machine if you're currently booted with a non smp kernel? [04:29] cat /proc/cpuinfo should list total cpu's [04:30] it doesn't if you don't have an SMP kernel, iirc [04:31] yup, verified on the live cd. [04:31] doesn't tell me about my second core, just my first one [04:31] (amd64) [04:32] probably doesn't parse core's, but it should parse cpu's [04:32] ncpus_probes should atleast [04:32] if not, it will be fixed in 2.6.15, since there were some patches for that [04:33] I don't have a real SMP machine here, so I can't test, but I've seen it not list all the CPUs listed before, at least. [05:00] Mithrandir: I have a non real SMP machine, and when using an SMP kernel I always see two CPUs === chuck_ [n=chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel [05:07] heylo === chuck_ is now known as zul [06:02] BenC: It looks like the bcm430x people are moving to using much the same 80211 code as the rtl8180 people [06:03] So with luck we'll have one softmac core for all of them === siretart [i=siretart@ubuntu/member/siretart] has joined #ubuntu-kernel [06:09] BenC: I noticed that iptables in breezy as well as in dapper there are some iptables modules missing, which are in debian's iptable [06:10] BenC: I filed therefore bugzilla #19978 [06:11] BenC: the most notably difference to debian is that debian uses an own copy of kernel headers. Do you have an idea how to fix this? [07:04] siretart: doesn't sound like something I can fix from the kernel side [07:04] everything in the kernel is enabled [07:05] mjg59: I have a softmac patch in -4.4 that came from the bcm430x ftp site [07:05] BenC: well, I suspected that iptables source isn't too happy with the headers the kernel does currently provide [07:05] because the kernel headers are the only difference [07:06] siretart: is that something that needs to change in the kernel, or just that iptables will need a hacked up copy of the headers for it's own build? [07:06] heh [07:06] one of my coworkers rebooted their hoary machine today. i totally forgot about the ABINAME bump [07:06] needless to say, openafs didn't work all that well for them, as there was no openafs module compiled for the new kernel [07:09] BenC: debian seems to ship with a hacked up copy of the headers. fabbione changed the iptables package to use the kernel headers instead [07:10] probably a good reason for that then [07:10] but you'd have to ask him about what that reason was :) [07:10] sounds to me like this is all squarely on the iptables package, so it's probably best to submit it as a bug against that package [07:11] well, there seems to be no direct maintainer, so I wanted to try to fix it [07:12] sure, if you fix it, then you can attach a patch to the bug report [07:13] you can assign it to fabbione since he touched the source, and probably get an explanation from him about it [07:14] or you can do the upload yourself, but I suggest atleast talking to fabbione first to find out why he switched it [07:16] I uploaded a merged iptables package today which didn't FTBFS ;) [07:17] I consider this as an improvement :) [07:26] siretart: an old working version and a new ftbfs version is a completely different situation than a new compiled-but-non-working version [07:26] since in the first case, apt-get dist-upgrade doesn't trash a working system [07:29] lamont-away: yeah, right [07:30] lamont-away: but a quick testrun showed my that iptables seems to be functional (I can look at my tables) [07:33] cool [07:34] but my original problem stands: There is no /lib/iptables/libipt_recent.so being built anymore. the new version from debian didn't bring any change [07:40] what are the criteria for the package building that module? [07:40] do you see any reference to it in the sources? [07:41] also, is it possible that regardless of the kernel headers, it is checking uname and seeing that maybe the kernel doesn't support an obsolete interface? === siretart rechecks [07:54] bye all [07:56] something is strange with linux-kernel-headers [07:56] linux-kernels-headers is an oddity by design [07:57] somehow all extensions of iptables get disabled when using linux-kernel-headers [07:58] perhaps thats the reason why iptables ships its own kernel headers [07:58] the problem is that the package FTBFS with that headers on ubuntu.. hmmm [07:59] siretart: iptables is probably one of those evil programs that defines __KERNEL__ when building userspace so it can get to some kernel internals [07:59] as such, linux-kernel-headers wont satisfy what it needs === zul [n=chuck@ubuntu/member/zul] has joined #ubuntu-kernel [08:01] iptables again [08:01] sign [08:02] I have an idea, let me try something.. [08:03] iptables does Very Bad Things, yes. [08:04] I think I got it [08:04] debian rules sets KERNEL_DIR to /usr/include, it has to be just '/usr' instead [08:05] interstingly, iptables seems to need the kernel includes only for some extensions, not for all, and not for itself.. [08:06] BenC: are you okay that I upload a package with just corrected KERNEL_DIR? quick check shows iptables works, even with '-m match' parameter [08:07] what do you mean "corrected KERNEL_DIR"? [08:08] BenC: http://paste.ubuntulinux.nl/4924 [08:08] thats the debdiff [08:10] looks good to me [08:10] ok. uploading [08:11] this patch should imo go to breezy-updates, too [08:12] because in breezy, there are no iptable extension modules atm [08:27] BenC: Yes, our lkh is designed to make those programs suck with low amounts of sympathy given. [08:27] well, iptables builds nicely with lkh [08:31] siretart: then iptables gets a gold star :) [08:31] :) [08:32] siretart: lkh are so hard to compile with for something that depends on the kernel? [08:33] sivang: I didn't touch lkh at all [08:49] aieeeeeeee [08:51] BenC: ok, I have some leads about the lockup [08:53] BenC: I have no digicam so that's what I managed to take by hand [08:53] BenC: pid 5570, comm modprobe [08:53] BenC: EIP:0060:[] CPU:0 [08:54] BenC: EIP is at _spin_lock_irqsave+0x14/0x20 [08:54] BenC: does that help? [08:54] do you have the first few functions from the stack trace? [08:54] sounds like it is crashing in a module init [08:54] need to know which module [08:55] BenC: how do I produce a stack trace there? I was virtually helpless when reaching that point [08:55] it didn't spit one out? [08:55] interesting [08:56] any idea what the error was above the pid 5570 line? [08:56] BenC: sure, the one I told you before [08:56] like "BUG: ..." [08:56] softlockup, that's right [08:56] BenC: the first echo was that is started PCMCIA detection stuff [08:57] BenC: yes [08:57] BenC: exactly [08:57] BenC: on CPU#0 [08:57] BenC: I wonder if I can reproduce that on this machine as well [08:57] I will isntall this kernel here as well [08:57] ok, -386 kernel works? if so, boot, and somehow disable pcmcia stuff [08:57] BenC: I can remove it's modules if they are there form /etc/modules ? [08:57] probably a script in /etc/hotplug/ for it [08:58] or try mv /lib/modules/(version)/kernel/drivers/pcmcia to somewhere outside of /lib/modules [08:58] ok, thanks for the tips [08:59] will try and let you know [08:59] ok, thanks [09:05] BenC: Yeah, I think that's being replaced with a more general solution [09:05] BenC: But basic Broadcom functionality seems to be getting fairly close [09:06] mjg59: well, they need something because ipw2200, bcm430x, prism54-softmac and rtl808x all seem to need it [09:07] rtl818x [09:07] and I'm getting tired if custom ieee80211 stacks in all our external wireless drivers :) [09:07] ipw2200 should just need the ieee80211 stack [09:07] it does, but it has internal softmac stuff [09:07] bcm430x, prism54-softmac and rtl808x need an extra softmac stack [09:07] Oh, does it? Nngh. [09:08] I thought it did all that in firmware [09:08] Oh well, never mind [09:08] the softmac patch for ieee80211 was partly based on ipw2200 [09:09] it may not need all the softmac, but it atleast has some functions that softmac needed (subset in ipw2200) [09:10] not to mention madwifi... [09:11] madwifi is a whole different kettle of fish. [09:11] madwifi needs porting to Linux [09:11] it has its own ieee80211 stack. Sure, it is fishy because of other reasons, too.. [09:11] At the moment it's a *BSD driver that's shoehorned into the kernel [09:15] BenC : Should I assume from your vacation announcement that I have until Monday to spit polish LRM? === spike [n=spike@unaffiliated/spike] has left #ubuntu-kernel ["bbl"] [09:15] infinity: yeah, definitely [09:15] about to upload -4.4, so you can base work off of that [09:15] Excellent. And we can shoot for an update -meta on Monday. [09:16] (Assuming other parties agree, I'll just upload -meta right after lrm builds everywhere) [09:16] I've decided that, after pulling an all-nighter, my Thursday is going to be a write-off. [09:17] Go me. [09:17] Anyhow. I should go catch some "oh god, the sun's already been up for two hours, eek" shuteye. [09:18] BenC: Is -4.4 one I should test for ppc64 love? [09:22] jbailey: I don't expect it to work, but surely give it a try [09:22] infinity: heh, get some sleep [09:27] BenC: If you're not expecting it to work, I'll just do it when I have time and not rush to it, then. [09:28] All good. =) [09:33] no problem :) === doko_ [n=doko@dslb-084-059-072-254.pools.arcor-ip.net] has joined #ubuntu-kernel [09:36] siretart: i have no issued with you working on iptables.. === LaschW [n=LaschW@dyndsl-085-016-016-057.ewe-ip-backbone.de] has joined #ubuntu-kernel [09:43] Are there any reports of segmentation fault booting linux-image-2.6.12-10-k7 ? [09:44] fabbione: a fixed version of iptables should be in dapper now on all arches [09:44] LaschW: no. works here. we did score 9/9 successes on the tests [09:44] fabbione: I think we should upload a fixed version of iptables to breezy-updates [09:44] siretart: what is exaclty broken? [09:45] fabbione: debian/rules sets the variable KERNEL_DIR to /usr/include [09:45] fabbione: this is wrong. it must be just '/usr' [09:45] specially given that nobody did notice up till now [09:45] fabbione: without the kernel headers, a lot of optional extra modules won't get built [09:45] siretart: and problems does that bring? [09:45] fabbione: extra modules like recent match support and quite a few others [09:46] hmmmm [09:46] I came to it because I wanted to play around with that 'recent' match target as suggested by someone on planet.debian.org [09:47] and was surprised that this doesn't work on breezy [09:49] i think it is a good candidate for -updates [09:49] siretart: i am confident you did your homework [09:49] fabbione: Is there a way how I may get / collect usefull information why this happens? [09:49] please explain to mdz and coordinate with him [09:49] LaschW: it depends what happens [09:50] LaschW: segfault what? what does segfault? [09:50] you didn't tell me much [09:50] fabbione: segfault before usplash started, si IMHO there are no logs in that state of boot, isn't it? [09:50] s/si/so/ [09:50] the kernel doesn't segfault [09:51] no there are no logs.. try to boot in recovery mode without usplash [09:51] what's on the screen? [09:51] can you take a picture? === zul__ [n=chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel [09:52] mdz: would you accept a one-line patch to iptabes for breezy-updates? Rationale: due to a wrong variable, iptables fails to find its kernel headers and does not compile nearly all optional modules. [09:52] fabbione: I will reproduce it and will see what I can do, give me a 1/4hour... === LaschW [n=LaschW@dyndsl-085-016-016-057.ewe-ip-backbone.de] has left #ubuntu-kernel ["Leaving"] [09:53] LaschW: in 1/4 hour i will be asleep [09:53] bah ok === ispiked [n=ispiked@unaffiliated/ispiked] has joined #ubuntu-kernel === ubuntulog [n=ubuntulo@port49.ds1-van.adsl.cybercity.dk] has joined #ubuntu-kernel === Topic for #ubuntu-kernel: Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-rc1-ubuntu2 uploaded (should build for x86, amd64, and ppc) === Topic (#ubuntu-kernel): set by BenC at Tue Nov 15 17:08:39 2005 [10:05] siretart: yes [10:06] siretart: send me a debdiff by mail for review [10:08] mdz: http://paste.ubuntulinux.nl/4924 [10:08] thats what I just uploaded to dapper, I'd upload of course with adjusted version number [10:09] siretart: go ahead and prepare the package and upload as 1.3.1-2ubuntu1.1 [10:09] to breezy-updates [10:10] on my way === LaschW [n=LaschW@dyndsl-085-016-009-044.ewe-ip-backbone.de] has joined #ubuntu-kernel [10:16] fabbione: linux-image2.6.12-10-k7 segfault during boot: [10:16] kernel doesn't segfault... [10:16] it OOPS [10:16] fabbione: Last message isa: uncompressing Linux... OK booting.... [10:17] fabbione:then 10 lines segmentation fault [10:17] fabbione: then a line: 0 [10:17] LaschW: -> initramfs [10:17] try regenerate the initramfs [10:17] fabbione: Ahh! [10:20] mm, neat [10:20] http://www.selenic.com/linux-tiny/ [10:21] fabbione: regenerating initramfs for 2.6.12-10-k7 will affect the other kernels? I'm asking because till now I have a running system, using the older kernel images. [10:21] no [10:21] no if you do it properly [10:23] fabbione: properly means: 'sudo dpkg-reconfigure linux-image-$(uname -r)' [10:24] yes [10:24] that is one [10:25] there are other ways [10:25]