[12:04] <BenC> and it uses rdtsc(), so it's x86 only
[12:04] <BenC> mjg59: any idea what a good portable replacement is for rdtsc()?
[12:05] <BenC> and when it says "work with current 802.11 stack", it means that in the loosest way
[12:05] <BenC> it's still using local ieee80211 headers, and abusing the real stack
[12:06] <mjg59> BenC: What fun
[12:07] <BenC> 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] <mjg59> What's it actually using rdtsc for?
[12:07] <mjg59> Ha
[12:07] <BenC> mjg59: filling in some hosttime in a struct
[12:08] <mjg59> Does it look important, or does it just need a monotonic timer?
[12:08] <BenC> mjg59: don't laugh, that's how I ended up taking over the ieee1394 stack :)
[12:08] <mjg59> Oh dear
[12:08] <BenC> it's something to do with a prism header
[12:09] <mjg59> Nngh.
[12:10] <mjg59> BenC: It only seems to be for monitor mode
[12:14] <mjg59> BenC: Other code just seems to use jiffies
[12:14] <BenC> it has it commented out to use jiffies near the top of that function
[12:14] <BenC> guess I'll do that aswell
[12:14] <mjg59> I'd just go back to that, TBH
[12:14] <mjg59> It seems to be a fairly standard 802.11 thing
[12:15] <BenC> wait, that's mac_time
[12:15] <BenC> oh well, I can use it still
[12:16] <mjg59> If you dig for hosttime in drivers/net/wireless, there's no shortage of hits
[03:39] <BenC> sweet
[03:39] <BenC> that is the most awesome tool and makes git totally worth using, even if it was the crappiest scm in the world
[07:52] <Earthpig> benc: would be nice if it could be automated.
[11:58] <CataEnry> hi all
[12:17] <CataEnry> cya
[12:23] <michel> i want to patch ltsp-kernel of ubuntu, howto? 
[01:50] <fabbione> BenC: is it possible to do firewire back to back?
[01:51] <fabbione> between 2 controllers i mean
[01:51] <fabbione> if so do i need a special cable or something?
[01:57] <CataEnry> hi all
[01:58] <BenC> fabbione: yeah
[01:58] <BenC> just a normal cable
[01:59] <BenC> think of firewire as a network where any device with more than one port is like a hub :)
[02:00] <BenC> I've had a winxp, macosx, 2 linux boxes, 3 firewire storage devices, firewire camera, all connected on a bus together
[02:00] <BenC> using IPover1394 between the winxp/macosx/linux boxes too
[02:00] <fabbione> ah cool
[02:00] <fabbione> ok
[02:00] <fabbione> i only have 2 boxes
[02:00] <fabbione> nothing fancy
[02:01] <fabbione> curious to try it
[02:01] <fabbione> probably more
[02:01] <fabbione> how fast can it go?
[02:02] <infinity> ~400 Mbps, in theory.
[02:02] <fabbione> that would be a cheap way to upgrade my 100Mb LAN to a ~ 400Mb
[02:02] <fabbione> or buy a gigabit switch
[02:02] <jbailey> fabbione: Do you actually have any disks that can push data that fast?
[02:02] <fabbione> but the latter is hutterly expensive
[02:03] <fabbione> jbailey: yes
[02:03] <jbailey> Handy. =)
[02:03] <BenC> fabbione: the linux IPover1394 isn't all that stable
[02:03] <fabbione> BenC: well.. it's a good way to push you to fix it :P
[02:03] <BenC> fabbione: not my driver :P
[02:04] <fabbione> still your kernel ;)
[02:04] <BenC> I just did the initial ethernet-over-1394, the RFC stuff came from someone else
[02:04] <BenC> the ethernet-over-1394 was really stable, since it was just a firewire packet wrapped around a normal ethernet packet
[02:04] <BenC> but it was linux-only
[02:05] <fabbione> yeah  i could guess so
[02:05] <fabbione> i guess i will switch to GigaEthernet
[02:05] <fabbione> build a 1394 network as backup
[02:05] <fabbione> and use the 100Mb for management
[02:05] <fabbione> or something like that
[02:05] <BenC> get some S800 firewire cards, and you'll almost be gigabit :)
[02:06] <fabbione> BenC: i have the cards.. i need the switch
[02:06] <fabbione> and a good switch is $$$
[02:06] <kiko> hey there
[02:06] <kiko> quick question
[02:06] <BenC> hey kiko
[02:07] <kiko> what's the difference between linux-image-2.6.10-6-686-smp and linux-image-2.6.10-5-686-smp?
[02:07] <BenC> kiko: about 4 revisions :)
[02:07] <fabbione> AHAHAHHAHA
[02:08] <kiko> really?
[02:08] <BenC> kiko: you'll need to be more specific than -6 and -5, since it could be -5.10 and -6.99
[02:08] <kiko> oh. those are just the package names
[02:08] <BenC> kiko: the functional difference is from -5 to -6, the kernel ABI changes
[02:08] <kiko> ii  linux-image-2.6.10-5-686-smp                 2.6.10-34.7
[02:09] <kiko> that's what we have installed
[02:09] <BenC> oh, I don't know how the revisions worked back then, I only know the current convention for breezy/dapper
[02:10] <kiko> hum hum
[02:10] <BenC> Bisecting: 2 revisions left to test after this
[02:11] <Earthpig> do you have vmware?
[02:12] <BenC> yes, but not installed right now
[02:12] <Earthpig> we use vmware 5's snapshots for that kind of iteration testing. 'tis wonderful.
[02:13] <fabbione> BenC: it's the same convention
[02:13] <fabbione> kiko: it's an ABI change
[02:13] <fabbione> you install the new one.. boot in the new one.. you are done
[02:13] <BenC> fabbione: I know the ABI bump is, but the 34.7 thing isn't :)
[02:13] <fabbione> oh right
[02:13] <fabbione> yes
[02:13] <fabbione> we did add the ABI number to the debian version only in breezy
[02:13] <BenC> Earthpig: for testing kernel regressions?
[02:13] <fabbione> the old pkgs have standard numbers
[02:14] <kiko> fabbione, should I be using the newer kernel or does it not really matter?
[02:14] <kiko> by newer kernel I mean newer-ABI-kernel
[02:14] <fabbione> kiko: well it's a security update that covers no less than 10 vulnerabilities
[02:14] <fabbione> kiko: it's up to you
[02:14] <fabbione> i suggest to use the new one
[02:14] <kiko> oh
[02:14] <kiko> so the -5 kernel was not updated?
[02:15] <kiko> ah. I think I understand the problem
[02:15] <kiko> I shouldn't have installed the -X kernel explicitly, right?
[02:15] <Earthpig> benc: well, we don't do kernels, so no. :)
[02:15] <BenC> kiko: the security update forced a bump to -6
[02:15] <kiko> I see
[02:15] <kiko> that's okay
[02:15] <kiko> so it won't automatically update?
[02:15] <kiko> (i.e. JRU does an apt-get update apt-get dist-upgrade and no new kernel)
[02:15] <BenC> not unless you have linux-image-686-smp installed
[02:15] <BenC> the meta-packages should pull in the upgrades
[02:15] <kiko> yeah, that's what I should have.
[02:16] <BenC> which is the default
[02:16] <Earthpig> benc: we do use it for automated testing of nightlies though.
[02:16] <BenC> Earthpig: cool
[02:16] <BenC> fabbione: I think -4.4 is going to go out today
[02:17] <BenC> after which I will attempt to get l-r-m built against 2.6.15, and then go for linux-meta
[02:17] <infinity> BenC : Please don't.
[02:17] <infinity> 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] <BenC> infinity: when's your next planned upload of l-r-m?
[02:18] <fabbione> BenC: ok.. but it's pointless to upload until the gcj thing is sorted
[02:18] <fabbione> BenC: basically all the archive is unbuildable atm
[02:18] <fabbione> BenC: plus infinity loves to spank l-r-m :)
[02:18] <infinity> BenC : I'll make l-r-m a priority tomorrow, since I expect to see X build tonight.
[02:18] <BenC> you people enjoy dashing my hopes don't you? :)
[02:19] <BenC> infinity: ok, I'll leave it alone, and just get linux-meta ready for when things settle down
[02:20] <infinity> I'd like to see CDs built with shiny new kernels too, so I'm on your side.  Don't worry. :)
[02:20] <infinity> Speaking of CDs, I really need to test that 640x400 vga16fb patch and get you to include it ASAP.
[02:20] <fabbione> BenC: Kamion wants to coordinate with you some udeb reorganization stuff
[02:21] <infinity> Certainly before we do the next flight CD anyway.
[02:22] <BenC> fabbione: yeah, I'm in #ubuntu-boot, but so far, I don't know what coordination I need to do
[02:22] <BenC> I was under the impression that once I got the kernel uploaded, the rest was on him :)
[02:22] <fabbione> BenC: basically Kamion wants to revert a few changes in the amount of udebs we do build
[02:22] <fabbione> BenC: yeah well.. he might need your help to setup git and stuff
[02:22] <BenC> infinity: yeah, I can test that on atleast one system where I know vga16 has always been broken
[02:22] <fabbione> he knows what needs to touch
[02:22] <infinity> BenC : Note that Kamion/Keybuk would really rather not see linux-meta updated until we're sure the udev stuff is sorted.
[02:23] <infinity> BenC : You have such a system?... ROCK THE FUCK ON.  I've been resigned to doing this blind until now. :)
[02:23] <BenC> 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] <BenC> I've been using vesa happily
[02:24] <BenC> fabbione: ok
[02:24] <fabbione> translating infinity to a more common language: "Dear Ben, given your card is broken, you win! FIX IT! kthxbye!"
[02:25] <BenC> lol
[02:25] <infinity> BenC : Hrm, not sure if this fix will fix your case, but bonus if it does.
[02:26] <BenC> 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] <BenC> rather wait for your patch before I touch vgacon at all
[02:27] <BenC> hrmm...not sure if I need to mark that last boot as git-bisect bad, or good
[02:28] <BenC> it booted way past where it normally crashed, but it got a segv in the initrd, and couldn't mount the rootdev
[02:29] <infinity> 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] <infinity> BenC : I just need to pick the "right" timings, and test the fuck out of them before I go blowing up people's hardware.
[02:48] <sivang> BenC: Hey Ben, 'sup? I installed 2.6.15 and am now getting "BUG: Soft lockup on CPU#0"
[02:48] <sivang> BenC: anything I can help to sovle this, or do more testing for you?
[02:49] <BenC> sivang: backtrace or oops of any kind?
[02:49] <sivang> BenC: if logs were not rotated, I should be able to give those . let's see
[02:51] <sivang> BenC: re: oops, machine can't boot past it. not even in "rescue" mode
[02:53] <sivang> BenC: can't seem to find it in the syslog, where else should I be looking?
[02:53] <BenC> dmesg
[02:53] <BenC> when it happens, does the machine lockup?
[02:53] <sivang> BenC: yes sir :)
[02:54] <CataEnry> re
[03:01] <spike> hi there
[03:03] <BenC> sivang: does Alt+SysRQ work?
[03:03] <spike> I was trying to get myself acquainted with dapper and thinking of kernel specs for dapper and ubuntu-server
[03:04] <spike> is selinux/grsec integration planned?
[03:04] <spike> and what about ELSA/CSA patches?
[03:04] <spike> or this sort of questions are welcome here?
[03:05] <spike> arent*
[03:07] <sivang> BenC: I will have to try. also, I can't seem to find the dmesg logs for that hangup
[03:07] <sivang> BenC: any tips on that?
[03:07] <sivang> BenC: (this all mean boot cycles for me)
[03:08] <BenC> sivang: if it was a lockup, it wont be there
[03:08] <BenC> 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] <sivang> BenC: ok, I will give it a try.
[03:09] <sivang> I'll be bak ;-)
[03:32] <sivang> BenC: now it locked up, on the corrupted USPlash screen , Alt+SysRq does nothing
[03:33] <infinity> sivang : If you boot without "splash" you can avoid usplash.
[03:33] <infinity> sivang : You might at least get some better debugging output then.
[03:34] <infinity> 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] <sivang> 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] <sivang> infinity: anyway, yet-another-boot-cycle
[03:41] <sivang> ok, couldn't see the "Soft lock" anymore
[03:42] <sivang> but I did see where it halted, again SysRq helped me none
[03:43] <sivang> [17179589.808000]  Intel ISA PCIC probe: not found. Before that I got "* /etc/network/options is deprecated"
[03:57] <sivang> BenC: any idea?
[03:57] <BenC> did alt+sysrq work?
[03:57] <BenC> ok, I see, no
[04:06] <CataEnry> brb
[04:08] <BenC> sivang: I'm at a loss, try booting with "noapic", "nolapic", etc, to see if that changes anything
[04:10] <sivang> 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] <BenC> sivang: at that point, the system dies, and likely is so trahed that opening a file would be disastrous
[04:18] <sivang> 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] <BenC> it could die before even being able to access the disk
[04:19] <sivang> ah right
[04:19] <sivang> darn
[04:19] <sivang> oh well, I will try again in a sec
[04:20] <sivang> BenC: btw, what nolapic does?
[04:20] <BenC> No Local APIC
[04:20] <sivang> k, thx
[04:20] <BenC> which kernel are you using anyway, -386, -686, -k7?
[04:22] <sivang> BenC: 686, the smp and UP enabled 
[04:22] <BenC> try doing "smp2up=off" aswell then
[04:22] <sivang> /boot/vmlinuz-2.6.15-3-686
[04:23] <sivang> and that tells it to?
[04:23] <BenC> are you on an SMP machine?
[04:24] <sivang> yes
[04:24] <BenC> then it wont do anything, so don't worry about it :)
[04:27] <sivang> 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] <BenC> cat /proc/cpuinfo should list total cpu's
[04:30] <Mithrandir> it doesn't if you don't have an SMP kernel, iirc
[04:31] <Mithrandir> yup, verified on the live cd.
[04:31] <Mithrandir> doesn't tell me about my second core, just my first one
[04:31] <Mithrandir> (amd64)
[04:32] <BenC> probably doesn't parse core's, but it should parse cpu's
[04:32] <BenC> ncpus_probes should atleast
[04:32] <BenC> if not, it will be fixed in 2.6.15, since there were some patches for that
[04:33] <Mithrandir> 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] <sivang> Mithrandir: I have a non real SMP machine, and when using an SMP kernel I always see two CPUs
[05:07] <chuck_> heylo
[06:02] <mjg59> BenC: It looks like the bcm430x people are moving to using much the same 80211 code as the rtl8180 people
[06:03] <mjg59> So with luck we'll have one softmac core for all of them
[06:09] <siretart> 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] <siretart> BenC: I filed therefore bugzilla #19978
[06:11] <siretart> 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] <BenC> siretart: doesn't sound like something I can fix from the kernel side
[07:04] <BenC> everything in the kernel is enabled
[07:05] <BenC> mjg59: I have a softmac patch in -4.4 that came from the bcm430x ftp site
[07:05] <siretart> BenC: well, I suspected that iptables source isn't too happy with the headers the kernel does currently provide
[07:05] <siretart> because the kernel headers are the only difference
[07:06] <BenC> 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] <dilinger> heh
[07:06] <dilinger> one of my coworkers rebooted their hoary machine today.  i totally forgot about the ABINAME bump
[07:06] <dilinger> 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] <siretart> 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] <BenC> probably a good reason for that then
[07:10] <BenC> but you'd have to ask him about what that reason was :)
[07:10] <BenC> 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] <siretart> well, there seems to be no direct maintainer, so I wanted to try to fix it
[07:12] <BenC> sure, if you fix it, then you can attach a patch to the bug report
[07:13] <BenC> you can assign it to fabbione since he touched the source, and probably get an explanation from him about it
[07:14] <BenC> or you can do the upload yourself, but I suggest atleast talking to fabbione first to find out why he switched it
[07:16] <siretart> I uploaded a merged iptables package today which didn't FTBFS ;)
[07:17] <siretart> I consider this as an improvement :)
[07:26] <lamont-away> 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] <lamont-away> since in the first case, apt-get dist-upgrade doesn't trash a working system
[07:29] <siretart> lamont-away: yeah, right
[07:30] <siretart> lamont-away: but a quick testrun showed my that iptables seems to be functional (I can look at my tables)
[07:33] <lamont-away> cool
[07:34] <siretart> 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] <BenC> what are the criteria for the package building that module?
[07:40] <BenC> do you see any reference to it in the sources?
[07:41] <BenC> 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?
[07:54] <CataEnry> bye all
[07:56] <siretart> something is strange with linux-kernel-headers
[07:56] <BenC> linux-kernels-headers is an oddity by design
[07:57] <siretart> somehow all extensions of iptables get disabled when using linux-kernel-headers
[07:58] <siretart> perhaps thats the reason why iptables ships its own kernel headers
[07:58] <siretart> the problem is that the package FTBFS with that headers on ubuntu.. hmmm
[07:59] <BenC> 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] <BenC> as such, linux-kernel-headers wont satisfy what it needs
[08:01] <kiko> iptables again
[08:01] <kiko> sign
[08:02] <siretart> I have an idea, let me try something..
[08:03] <infinity> iptables does Very Bad Things, yes.
[08:04] <siretart> I think I got it
[08:04] <siretart> debian rules sets KERNEL_DIR to /usr/include, it has to be just '/usr' instead
[08:05] <siretart> interstingly, iptables seems to need the kernel includes only for some extensions, not for all, and not for itself..
[08:06] <siretart> 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] <BenC> what do you mean "corrected KERNEL_DIR"?
[08:08] <siretart> BenC: http://paste.ubuntulinux.nl/4924
[08:08] <siretart> thats the debdiff
[08:10] <BenC> looks good to me
[08:10] <siretart> ok. uploading
[08:11] <siretart> this patch should imo go to breezy-updates, too
[08:12] <siretart> because in breezy, there are no iptable extension modules atm
[08:27] <jbailey> BenC: Yes, our lkh is designed to make those programs suck with low amounts of sympathy given.
[08:27] <siretart> well, iptables builds nicely with lkh
[08:31] <BenC> siretart: then iptables gets a gold star :)
[08:31] <siretart> :)
[08:32] <sivang> siretart: lkh are so hard to compile with for something that depends on the kernel?
[08:33] <siretart> sivang: I didn't touch lkh at all
[08:49] <zul> aieeeeeeee
[08:51] <sivang> BenC: ok, I have some leads about the lockup
[08:53] <sivang> BenC: I have no digicam so that's what I managed to take by hand
[08:53] <sivang> BenC: pid 5570, comm   modprobe
[08:53] <sivang> BenC: EIP:0060:[<c02ec3d4>]  CPU:0
[08:54] <sivang> BenC: EIP is at _spin_lock_irqsave+0x14/0x20
[08:54] <sivang> BenC: does that help?
[08:54] <BenC> do you have the first few functions from the stack trace?
[08:54] <BenC> sounds like it is crashing in a module init
[08:54] <BenC> need to know which module
[08:55] <sivang> BenC: how do I produce a stack trace there? I was virtually helpless when reaching that point
[08:55] <BenC> it didn't spit one out?
[08:55] <BenC> interesting
[08:56] <BenC> any idea what the error was above the pid 5570 line?
[08:56] <sivang> BenC: sure, the one I told you before
[08:56] <BenC> like "BUG: ..."
[08:56] <BenC> softlockup, that's right
[08:56] <sivang> BenC: the first echo was that is started PCMCIA detection stuff
[08:57] <sivang> BenC: yes
[08:57] <sivang> BenC: exactly
[08:57] <sivang> BenC: on CPU#0
[08:57] <sivang> BenC: I wonder if I can reproduce that on this machine as well
[08:57] <sivang> I will isntall this kernel here as well
[08:57] <BenC> ok, -386 kernel works? if so, boot, and somehow disable pcmcia stuff
[08:57] <sivang> BenC: I can remove it's modules if they are there form /etc/modules ?
[08:57] <BenC> probably a script in /etc/hotplug/ for it
[08:58] <BenC> or try mv /lib/modules/(version)/kernel/drivers/pcmcia to somewhere outside of /lib/modules
[08:58] <sivang> ok, thanks for the tips
[08:59] <sivang> will try and let you know
[08:59] <BenC> ok, thanks
[09:05] <mjg59> BenC: Yeah, I think that's being replaced with a more general solution
[09:05] <mjg59> BenC: But basic Broadcom functionality seems to be getting fairly close
[09:06] <BenC> mjg59: well, they need something because ipw2200, bcm430x, prism54-softmac and rtl808x all seem to need it
[09:07] <BenC> rtl818x
[09:07] <BenC> and I'm getting tired if custom ieee80211 stacks in all our external wireless drivers :)
[09:07] <mjg59> ipw2200 should just need the ieee80211 stack
[09:07] <BenC> it does, but it has internal softmac stuff
[09:07] <mjg59> bcm430x, prism54-softmac and rtl808x need an extra softmac stack
[09:07] <mjg59> Oh, does it? Nngh.
[09:08] <mjg59> I thought it did all that in firmware
[09:08] <mjg59> Oh well, never mind
[09:08] <BenC> the softmac patch for ieee80211 was partly based on ipw2200
[09:09] <BenC> it may not need all the softmac, but it atleast has some functions that softmac needed (subset in ipw2200)
[09:10] <siretart> not to mention madwifi...
[09:11] <infinity> madwifi is a whole different kettle of fish.
[09:11] <mjg59> madwifi needs porting to Linux
[09:11] <siretart> it has its own ieee80211 stack. Sure, it is fishy because of other reasons, too..
[09:11] <mjg59> At the moment it's a *BSD driver that's shoehorned into the kernel
[09:15] <infinity> BenC : Should I assume from your vacation announcement that I have until Monday to spit polish LRM?
[09:15] <BenC> infinity: yeah, definitely
[09:15] <BenC> about to upload -4.4, so you can base work off of that
[09:15] <infinity> Excellent.  And we can shoot for an update -meta on Monday.
[09:16] <infinity> (Assuming other parties agree, I'll just upload -meta right after lrm builds everywhere)
[09:16] <infinity> I've decided that, after pulling an all-nighter, my Thursday is going to be a write-off.
[09:17] <infinity> Go me.
[09:17] <infinity> Anyhow.  I should go catch some "oh god, the sun's already been up for two hours, eek" shuteye.
[09:18] <jbailey> BenC: Is -4.4 one I should test for ppc64 love?
[09:22] <BenC> jbailey: I don't expect it to work, but surely give it a try
[09:22] <BenC> infinity: heh, get some sleep
[09:27] <jbailey> 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] <jbailey> All good. =)
[09:33] <BenC> no problem :)
[09:36] <fabbione> siretart: i have no issued with you working on iptables..
[09:43] <LaschW> Are there any reports of segmentation fault booting linux-image-2.6.12-10-k7 ?
[09:44] <siretart> fabbione: a fixed version of iptables should be in dapper now on all arches
[09:44] <fabbione> LaschW: no. works here. we did score 9/9 successes on the tests
[09:44] <siretart> fabbione: I think we should upload a fixed version of iptables to breezy-updates
[09:44] <fabbione> siretart: what is exaclty broken?
[09:45] <siretart> fabbione: debian/rules sets the variable KERNEL_DIR to /usr/include
[09:45] <siretart> fabbione: this is wrong. it must be just '/usr'
[09:45] <fabbione> specially given that nobody did notice up till now
[09:45] <siretart> fabbione: without the kernel headers, a lot of optional extra modules won't get built
[09:45] <fabbione> siretart: and problems does that bring?
[09:45] <siretart> fabbione: extra modules like recent match support and quite a few others
[09:46] <fabbione> hmmmm
[09:46] <siretart> 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] <siretart> and was surprised that this doesn't work on breezy
[09:49] <fabbione> i think it is a good candidate for -updates
[09:49] <fabbione> siretart: i am confident you did your homework
[09:49] <LaschW> fabbione: Is there a way how I may get / collect usefull information why this happens? 
[09:49] <fabbione> please explain to mdz and coordinate with him
[09:49] <fabbione> LaschW: it depends what happens
[09:50] <fabbione> LaschW: segfault what? what does segfault?
[09:50] <fabbione> you didn't tell me much
[09:50] <LaschW> fabbione: segfault before usplash started, si IMHO there are no logs in that state of boot, isn't it?
[09:50] <LaschW> s/si/so/
[09:50] <fabbione> the kernel doesn't segfault
[09:51] <fabbione> no there are no logs.. try to boot in recovery mode without usplash
[09:51] <fabbione> what's on the screen?
[09:51] <fabbione> can you take a picture?
[09:52] <siretart> 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] <LaschW> fabbione: I will reproduce it and will see what I can do, give me a 1/4hour...
[09:53] <fabbione> LaschW: in 1/4 hour i will be asleep
[09:53] <fabbione> bah ok
[10:05] <mdz> siretart: yes
[10:06] <mdz> siretart: send me a debdiff by mail for review
[10:08] <siretart> mdz: http://paste.ubuntulinux.nl/4924
[10:08] <siretart> thats what I just uploaded to dapper, I'd upload of course with adjusted version number
[10:09] <mdz> siretart: go ahead and prepare the package and upload as 1.3.1-2ubuntu1.1
[10:09] <mdz> to breezy-updates
[10:10] <siretart> on my way
[10:16] <LaschW> fabbione: linux-image2.6.12-10-k7 segfault during boot: 
[10:16] <fabbione> kernel doesn't segfault...
[10:16] <fabbione> it OOPS
[10:16] <LaschW> fabbione: Last message isa: uncompressing Linux... OK booting....
[10:17] <LaschW> fabbione:then 10 lines segmentation fault
[10:17] <LaschW> fabbione: then a line: 0
[10:17] <fabbione> LaschW:  -> initramfs
[10:17] <fabbione> try regenerate the initramfs
[10:17] <LaschW> fabbione: Ahh!
[10:20] <dilinger> mm, neat
[10:20] <dilinger> http://www.selenic.com/linux-tiny/
[10:21] <LaschW> 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] <fabbione> no
[10:21] <fabbione> no if you do it properly
[10:23] <LaschW> fabbione: properly means: 'sudo dpkg-reconfigure linux-image-$(uname -r)'
[10:24] <fabbione> yes
[10:24] <fabbione> that is one
[10:25] <fabbione> there are other ways
[10:25] <fabbione> but use that one
[10:25] <LaschW> fabbione: OK, thanks a lot...
[10:26] <fabbione> i have the feeling i am going to get pissed soon
[10:26] <fabbione> there is a user that keeps bombing me of emails in pvt
[10:27] <BenC> fabbione: bounce them all back to him, maybe he'll stop
[10:27] <BenC> fabbione: I saw one report that sound stopped working with 2.6.12-10
[10:28] <fabbione> BenC: i did answer him and CC kernel-team
[10:28] <fabbione> let see if he gets the clue (again)
[10:28] <fabbione> BenC: quite impossible.. sound didn't change
[10:28] <fabbione> bug number?
[10:29] <BenC> 19969
[10:29] <zul__> meh...since when did kernel-team ml become support
[10:30] <BenC> it's very vague
[10:30] <BenC> like, I think I just gave you all the info in the bug report
[10:31] <zul__> shoot em
[10:34] <zul__> how ubuntite of me ;)
[10:35] <zul__> later anyways
[10:35] <fabbione> wow
[10:35] <fabbione> what a bug
[10:36] <fabbione> BenC: let the bug die there for the next 2/3 weeks and close it with prejudist
[10:36] <fabbione> bug is pointless. kthxbye
[10:36] <fabbione> or ask Diziet to do it for you
[10:36] <fabbione> ;)
[10:42] <LaschW> fabbione: 'sudo dpkg-reconfigure linux-image-2.6.12-10-k7' didn't change anything. Still segfault messages...
[10:43] <fabbione> LaschW: works here... ask jbailey how to debug initramfs
[10:43] <LaschW> fabbione: dpkg-reconfigure says: Not touching initrd symlinks since we are being reinstalled (2.6.12-10.24)
[10:43] <BenC> lol
[10:43] <fabbione> the kernel is ok
[10:44] <BenC> the only way to know for sure is to regen the initramfs for the old kernel and see if that works
[10:44] <BenC> you could also try the -386 kernel
[10:44] <fabbione> yeah that's another option too
[10:45] <fabbione> but i am pretty sure the kernel is fine
[10:45] <fabbione> specially because my k7 is one of the test machines
[10:46] <fabbione> oh JEEE
[10:46] <fabbione> this guy is persistent
[10:46] <fabbione> CC to kernel-team
[10:46] <fabbione> he answer back without kernel-team
[10:47] <BenC> he's embarassed :)
[10:47] <fabbione> I AM PISSED
[10:48] <fabbione> why nobody cares about pissed Developers but only about embarassed (l)users? ;)
[10:48] <fabbione> THEY SHOULD ALL DIE A PAINFUL DEATH!
[10:48] <fabbione> ah
[10:48] <fabbione> steaming down is healty
[10:49] <LaschW> But how does it come that the 2.6.12-9-k7 works and the -10-k7 not? Just for beeing curious...
[10:49] <fabbione> LaschW: the kernel works fine. the segfault is not coming from the kernel
[10:50] <fabbione> the initramfs is probably corrupted or it is not generated properly
[10:50] <fabbione> otherwise you won't see a segfault
[10:50] <fabbione> but an OOPS
[10:50] <fabbione> and it can be anything that breaks the initramfs
[10:50] <fabbione> really...
[10:50] <fabbione> LaschW: try booting 2.6.12-10-386
[10:50] <fabbione> and see if it works
[10:51] <fabbione> none of the security patches to touch boot
[10:51] <fabbione> boot process i mean
[10:51] <fabbione> anyway i am off to bed
[10:51] <fabbione> good night *
[11:14] <mdke> hello
[11:15] <mdke> i had some bugs about acx_pci closed without a comment recently. They are still reproduceable on dapper, how come they were closed, does anyone know?
[11:16] <jbailey> mdke: Bug number?
[11:17] <mdke> hmm
[11:17] <mdke> lemme find them
[11:21] <mdke> jbailey, i can't find them, i'll have to come back when I have my email with me
[11:24] <mdke> perhaps it was just housecleaning, and closing bugs instead of marking them as dups