[03:05] <jcole> how do i tell apt to not prompt with the "Are you sure you want to remove running kernel" message
[03:06] <infinity> That's not apt, that's the linux-image prerm.
[03:07] <jcole> damn
[06:40] <BenC> lamont: ping
[01:45] <zul> heylo
[02:34] <zul> wohoo...i get to do a cluser at work
[02:38] <infinity> Is that a loser without a clue?
[02:38] <infinity> And is she cute?
[02:39] <zul> cluster even...need more coffee brb
[04:47] <lamont> BenC: ack
[04:48] <BenC> lamont: hey
[04:48] <BenC> lamont: hppa (with it's binutils bug) is the only arch I don't have booting 2.6.17 now
[04:49] <BenC> lamont: any ideas who I can talk to, or what I can do to help this along?
[04:51] <BenC> lamont: is there any way to tell from userspace that a module is affected by this problem?
[04:51] <BenC> is there a relocation I can look for in objdump output or something?
[04:58] <lamont> it's the PCREL17 (or whatever it is) reloc that occurs more than 2^16 bytes into the section
[05:00] <BenC> I don't see any PCREL17, but I do see a lot of PCREL22's
[05:01] <BenC> which is the one mentioned in the kernel mentioned in the kernel output when it tried to load it
[05:01] <fabbione> BenC: that's hppa64, right?
[05:01] <BenC> yeah
[05:01] <fabbione> yeah you get PCREL17 on 32
[05:01] <BenC> 00000000000002cc R_PARISC_PCREL22F  printk
[05:02] <lamont> yeah - more bits on 64-bit, same issue
[05:03] <lamont> the issue is that the fixup location (thanks to ld -r) is more than 22-signedbits of displacement from the start of the section, and doesn't reach the target.
[05:03] <lamont> possible workarounds include compiling with long branches instead of stubs for all modules (then they fit, but it runs slower)
[05:04] <BenC> is that a linker option?
[05:04] <BenC> and can it be a per module option, or is it something that affects the ABI of the whole kernel?
[05:05] <fabbione> per module is a suicide
[05:06] <lamont> it's a compile-time option (not linker), which could be tied to all modules - note that there is a performance penalty for it
[05:07] <lamont> the other option is to quit using ld -r to link in each and every .o one by one into the module.
[05:08] <BenC> so this is also caused by the way the kernel is linking and the number of object files?
[05:08] <lamont> pretty much, yes.
[05:08] <lamont> the short summary of the bug is that "ld -r creates unlinkable sections because it doesn't keep the sections split, or add fixups as needed to be linkable"
[05:09] <lamont> if there's an option to ld -r to have it leave each .o in its own section, that'd solve the issue too
[05:10] <lamont> if gcc creates a section that is too large to link, it switches over to long-branches at the critical point.  ld -r doesn't do that.
[05:17] <BenC> lamont: can you check "man ld" and see if --unique sounds like what you were talking about?
[05:18] <lamont> should do it, and shouldn't be that painful if it's just applied to modules.  /me asks in #parsic
[05:21] <lamont> BenC: it certainly looks close enough to try a test with it 
[05:21] <lamont> (mind you, just on the ld -r in modules...)
[05:22] <BenC> ok, I'm going to add it to LDFLAGS_MODULES and see
[05:28] <BenC>   hppa64-linux-gnu-ld   -r --unique -o fs/jbd/jbd.o fs/jbd/transaction.o fs/jbd/commit.o fs/jbd/recovery.o fs/jbd/checkpoint.o fs/jbd/revoke.o fs/jbd/journal.o
[05:28] <BenC> well, that's what I got it to do, so let's see if it does the right thing
[05:37] <BenC> going to take 30 minutes to do this full build, I'll keep you posted
[05:45] <lamont> Subject:  	I don't want the whole world, just your half
[05:50] <lamont> there... nothing more than 4 weeks old... sigh
[05:52] <lamont> fabbione: zul: I might have changed the moderator password for kernel-{teams,bugs} - if so, holler and I'll send you both the new one... (since you're listed as moderators...)
[05:53] <fabbione> lamont: you can remove me please
[05:53] <fabbione> i don't bash the kernel enough to handle the lists
[05:53] <lamont> ok
[05:54] <lamont> fabbione: fired.
[05:54] <lamont> er, removed
[05:54] <lamont> (just from moderation)
[05:54] <fabbione> lamont: ehhehe
[05:59] <zul> lamont: i dont think i ever had the password
[06:02] <zul> yay...dpkg-deb: building package `linux-image-2.6.10-6-k7-smp' in `../linux-image-2.6.10-6-k7-smp_2.6.10-34.18_i386.deb'.
[06:04] <lamont> zul: that's kinda old...
[06:04] <lamont> zul: you want the moderation passwd?
[06:04] <zul> sure...send me any email
[06:05] <lamont> will do in a bit
[06:05] <zul> okie dokie
[06:05] <zul> lamont: yeah i know its old but 34.18 is kind of newish
[06:05] <lamont> heh
[06:06] <zul> i have to boot it when i get home tonight
[06:14] <BenC> you probably wont get much functionality out of it, but as long as it boots, that should be a good test
[06:15] <zul> im just going to install qemu and get it to boot
[06:15] <zul> it only built the x86 ones though
[06:36] <BenC> lamont: I see some changes in the relocation tables (references to new .# sections)
[06:36] <BenC> but this keeps me from being optimistic
[06:36] <lamont> sounds promising
[06:36] <BenC> root@hippo:~# hppa64-linux-gnu-objdump -r /lib/modules/2.6.15-23-hppa64-smp/kernel/fs/ocfs2/ocfs2.ko | grep PCREL | wc -l
[06:36] <BenC> 3521
[06:36] <BenC> root@hippo:~# hppa64-linux-gnu-objdump -r /org/ubuntu-2.6/debian/build/build-hppa64-smp/fs/ocfs2/ocfs2.ko | wc -l
[06:36] <BenC> 21781
[06:36] <BenC> oops
[06:37] <BenC> last one should read ~3400
[06:37] <lamont> having the PCREL22 fixups is fine... having them too far from the start of a section is bad
[06:37] <BenC> 3400 relocations is still > MAX_GOTS
[06:37] <BenC> but module.c wont allow a module with > 1023 PCREL's
[06:37] <lamont> oh... we should fix that. :-)
[06:38] <lamont> 4095 is still reasonable, no?
[06:38] <BenC> sure :)
[06:38] <BenC> I'll see if the relocations even got fixed up right in a minute
[06:44] <BenC> boot in progress
[08:49] <BenC> zul: Don't worry about dapper security, I'm working on it now
[08:49] <zul> ok
[08:49] <zul> ill worry about the next one
[08:51] <zul> BenC: for the next dapper security should i just send a patch to you or how is that going to work for git?
[08:52] <BenC> nah, git tree that I can pull from
[08:52] <zul> ok
[08:52] <BenC> or use git to create a patch set that I can pull in with git-applymbox like I do with crimsun's sound stuff
[08:53] <crimsun> (git-format-patch)
[08:53] <zul> but ill still be collecting little trival patches as well
[08:54] <zul> build it, upload it and then push patches to you?
[08:56] <zul> or something like that
[08:57] <BenC> dapper is so much easier for CVE's
[08:58] <BenC> git-cherry-pick is my friend
[08:58] <zul> yeah i know..hoary is a pain in the ass breezy will be a bit better dapper will be easy (in theory)
[08:59] <zul> oooo...polygamy is legal in canada now
[08:59] <zul> well not legal recognized..
[09:00] <BenC> polygamy?
[09:01] <BenC> poly gambling?
[09:01] <zul> polygamy...multiple wives
[09:01] <BenC> oh
[09:01] <BenC> it sort of legal in the US if you got them all from another country, but not recognized on taxes and such :)
[09:02] <zul> its recognized for taxes in canada now..
[09:02] <BenC> there's a minimart owner near hear that has like 3 wives he brought with him from some mideast country
[09:02] <BenC> s/hear/here/
[09:02] <BenC> they never speak, they just take care of the 10 kids running around
[09:02] <zul> mean, *buntu have certainly raised the bar, so more bugs is pretty much a reflection of that
[09:03] <zul> oops..
[09:03] <crimsun> (thanks ;-)
[09:03] <zul> http://cnews.canoe.ca/CNEWS/Politics/2006/05/31/1608364-sun.html
[09:03] <zul> crimsun: no probs
[11:58] <zul> heylo
[11:59] <zul> BenC: ping
[11:59] <BenC> zul: polongy
[11:59] <zul> 34.18 boots
[11:59] <BenC> swee
[11:59] <zul> er...2.6.10 yay!
[11:59] <BenC> t
[11:59] <zul> the 686 image at least
[12:00] <zul> ill have to modify my changelog and ill do an upload is there anything else i have to do