=== crimsun [~crimsun@rchp4.rochester.ibm.com] has joined #ubuntu-kernel === karlheg [~karlheg@host-250-237.resnet.pdx.edu] has joined #ubuntu-kernel === crimsun [~crimsun@rchp4.rochester.ibm.com] has joined #ubuntu-kernel === crimsun [~crimsun@66-188-220-125.dhcp.roch.mn.charter.com] has joined #ubuntu-kernel [05:44] morning === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-kernel === jbailey [~jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-kernel [06:43] hey jbailey [06:44] Heya Fabio [06:44] I'm about to upload initramfs-tools 0.14 [06:44] nice [06:44] Just need to figure out why bzr doesn't feel like commiting. [06:44] jbailey: did you hear anything about binutils to fix that link problem on sparc? [06:44] No, but I haven't had a chance to dig in yet. [06:45] Sorry about that. =( [06:45] no need to be sorry please [06:45] :) [06:45] i was only asking... [06:46] the situation still looks good [06:46] Well, I feel bad that I haven't had a chance. [06:46] Feeling a bit swamped. [06:46] but the gnome pkgs starts to pile up [06:46] bzr commit done. [06:46] This version actually now detects IDE correctly on my box, SATA on another one, and LVM and Raid1. [06:47] nice [06:47] i hope i won't crash today [06:47] and give it a shot [06:48] i am so tired you have no idea [06:48] Still no evms or cryptroot. [06:48] I just don't have test scenarios for those, so it'll be a bitch. [06:48] if you have md and lvm you also have evms [06:48] I do? [06:48] I'll ask you sometime when I'm awake. [06:49] I promised mdz that I'd put out a call for testers today on what I have. [06:49] as it stands now.. evms and lvm are "only" 2 interfaces towards device-mapper [06:49] if you get one, somehow you get the other [06:49] Ah, okay. [06:49] but mdz can give you more details about evms [06:49] he was the maintainer [06:49] 'cept that he's insanely busy. [06:49] well he can spend 2 minutes [06:50] at least this is at kernel level.. [06:50] if userland does something "weird" i dunno [06:50] i was never able to make evms work in a decent way [06:51] evms ate my partition table [06:51] So I'm not inclined to try it again. [06:52] ehhe [06:58] Rejected: binary uploads are not allowed - please only upload source. [06:58] Bah [06:58] I must get that wrong like *half* the time. [06:59] ehhehe === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-kernel [07:12] jbailey: when i am linking.. can i avoid to specify -m $emulation ? [07:12] or is it somewhat mandatory? [07:12] Mmm, I thought it was supposed to detect it from the module. [07:12] I might be mistaken. [07:12] what i mean is: [07:12] It's been so long since I've used ld directly. [07:12] ld -m elf_i386 -r -o $dest $modules [07:13] Right. [07:13] if i omit -m elf_i386, which one will be selected? [07:13] I think you ought to be able to leave it out. [07:13] It should be detected, so in this case elf_i386 [07:13] i guess i need to try it [07:14] yeah it works on i386 [07:34] Sleep time. === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-kernel === JaneW [~JaneW@wbs-146-168-164.telkomadsl.co.za] has joined #ubuntu-kernel === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-kernel === chmj [~chmj@196.36.161.235] has joined #ubuntu-kernel === horms [~horms@vagw.valinux.co.jp] has joined #ubuntu-kernel === doko [~doko___@dsl-084-059-067-130.arcor-ip.net] has joined #ubuntu-kernel === jbailey [~jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-kernel === chmj [~chmj@196.36.161.235] has joined #ubuntu-kernel [02:24] fabbione: Hey - did you get a chance to try the initramfs-tools stuff at all? [02:25] no :( === zul [~chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel [02:28] heylo [02:29] hey zul [02:29] hey how is it going? [02:32] as usual [02:34] exciting [02:35] what's exciting about it? [02:46] i was being sarcastic === lamont__ [~lamont@15.238.5.126] has joined #ubuntu-kernel [04:33] fabbione: rebooting now [04:33] kw33l [04:36] well. that was painful [04:36] so? [04:36] good news for doko... it's not 3.4 [04:36] bad news for the ia64 porter :P [04:36] bad news for me: it's not 3.4 [04:36] yeppers [04:37] means I have to actually work on it. [04:37] lamont__: the only thing i try to do is disable acpi on ia64 [04:37] ?? [04:37] it's the only big ia64 chunk of code that's different from Debian [04:37] sorry. "i would try to do".. [04:37] I should try booting with noacpi? or there's a kernel patch I should try removing? [04:37] try booting with noacpi first [05:16] W00t Got my drivers license. [05:17] Angie has to wait until she gets better proof of residence. [05:17] So stupid. [05:17] its the same in ontario dude [05:18] Umm, no. [05:18] Her lease was good enough, and a bank statement was good enough for me. [05:18] well..for health card i guess [05:18] Well + old license. =) [05:19] But here, I needed passport, ontario health card, ontario drivers license, and a current bill showing transactions only in quebec since I moved sent to this address. [05:19] Andit has to be a bill from a 'respectable place' [05:19] so pornos are out? :) [05:19] The fact that she bought $3500 worth of appliances from Future Shop that got sent to the appartment that she leased isn't good enough. [05:20] Nor is the confirmation from Hydro Quebec saying that her account is now open good enough. [05:21] She had a visa bill with her, but the lady just said that it doesn't matter. The bank will send a statememnt anywhere. [05:21] *my* visa bill was fine, though, since it has a u-haul on it, a bunch of gas stops along the 401 and a dozen or so transactions in montreal after that. [05:21] lol...stupid quebec [05:23] I thought it was a bit extreme. [05:23] But I got mine for now, anyway. [05:24] The Hydro bill is in her name, so when that gets sent, that'll be good enough. [05:28] getting married in quebec is pretty extreme i hear as well [05:34] Oh? [05:34] What's the story there? [05:35] i dont really remmeber unforuntately.. [05:45] fabbione: ping? [05:45] fabbione: any idea if this is going anywhere upstream: http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initrd-v0.7d-2.6.12.patch [05:47] jbailey: acpi -> mjg59 .. really... [05:48] Hmm. This is more initramfs handling, but alright. =) [05:48] mjg59_: *poke* ^^^ [05:48] It looks like we need to apply either that one or this one: [05:48] http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initramfs-fix-2.6.10-cleanup.patch [05:52] acpi upstream aren't keen on it [05:53] If it's needed for initramfs, then push it [05:54] mjg59_: the ia64 issue is more basic... nothing from the kernel but timeout/machine-checks [05:54] lamont__: Mm? [05:54] 2.6.10-5 boots fine and all, 2.6.12-current is not so happy. with or without 'noacpi' [05:54] so somewhere in there, I have issues to figure out. [05:54] Can you revert the acpi patch? [05:54] could be a fun little bios interaction [05:55] Hmm. Hang on - I seem to remember something that may be related. Hang on. [05:55] mjg59_: that's certainly on the list... [05:55] mjg59_: the "one console" issue? [05:55] mjg59_: Do they have specific concerns that I should work with? Having it right in the filesystem is elegant in a number of ways. [05:55] jbailey: "Vendors should fix their hardware" [05:55] mjg59_: Not the least of which that you can swap dsdt's at boottime with a trivial hack to grub. [05:56] lamont__: If it boots without that, can you grab the latest bleeding-edge ACPI patch and see if that's any better? [05:57] mjg59_: certainly. will probably pester you for where to grab said bleeding-edge razor [05:58] fabbione: I have a really strong preference of the acpi-dsdt-initrd-v0.7d.... patch. It has the advantage that if someone does a custom kernel, they just won't get a DSDT. With the other one, if they run a stock kernel, the kernel can't load an initramfs with a DSDT in it. [05:58] mjg59_, fabbione: What prep/testing do you need me to do in order to test it adequately for you to bless it? [05:59] jbailey: are the 2 patches mutal exclusive? [05:59] so it's either one or the other [05:59] No [05:59] jbailey: The initramfs one looks correct. Break your DSDT, boot with it, see if your machine breaks [05:59] If so, I'm happy with it [05:59] mjg59_: The one that just alters the read size to compensate for the DSDT hanging off the end? [05:59] Hang on === jbailey hangs [06:00] ding dong the wicked witch...er.. [06:00] jbailey: Ok. What's the precise issue? [06:00] zul: Funny enough, there are bells rining outside. [06:01] lol [06:02] mjg59_: With an initramfs, using the traditional way of appending the DSDT to the initramfs causes a boot failure. The people at this web site are proposing two solutions. 1) (http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initramfs-fix-2.6.10-cleanup.patch) makes the initramfs read function calculate the size of the initramfs without including the files so that it unpacks the initramfs correctly. The rest of th [06:02] e sstem should go on to process the dsdt correctly. [06:02] Yes. That looks clean enough. [06:02] 2) http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initrd-v0.7d-2.6.12.patch makes the initramfs system available earlier so that acpi can simply open the file off of the filesystem and read it in. [06:02] Right. I've no preference. [06:02] The first seems less invasive [06:03] So here's the catch. [06:03] 1) Means that if someone does a custom kernel, but includes a DSDT at the end, they won't have the patch, so the machine won't boot. [06:03] Yes [06:03] 2) Means that if someone does a custom kernel, and includes a DSDT in the initramfs, it simpy won't get read by anything. [06:03] Well, either is fine with me. [06:04] Have you seen either of these on upstream lists? I have a preference for #2 to reduce the support nightmare. [06:04] But I suspect that #1, being less invasive, is more likely to get accepted. But that's entirely a guess. [06:04] Neither is going to make it upstream while acpi upstream are hostile [06:04] If neither will make it upstream, then I'll do #2 =) === desrt [~desrt@dhcp-0-20-af-d2-7c-3.cpe.mountaincable.net] has joined #ubuntu-kernel [06:06] fabbione: What sort of testing do you want me to do before I say "Please include this patch"? [06:07] jbailey: it's enough it works for you.... [06:08] 'kay [06:08] I guess I need to figure out how to compile a kernel now. =) [06:08] it looks to me we already have 2 === jbailey blinks [06:08] Oh? === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-kernel === jbailey apt-get source's the kernel to check [06:10] fabbione: I think we only have an earlier version of the patch that doesn't deal with initramfs [06:10] Hmm, can I apt-get source the i386 kernel from a ppc? === jbailey hops onto concordia [06:11] jbailey: the kernel is only one [06:11] there is only ONE source [06:11] use the source luke [06:12] mjg59_: well i have no issues to update it.. [06:12] Ah, handy === jbailey blinks. [06:12] 26k source? [06:13] Oh, that's linux-meta [06:13] 47mb, much better [06:15] Err.. Is i386 only at 2.6.12-3 ? [06:15] That's all concordia seems to have in its chroot's apt sources [06:19] jbailey: you can grab the sources from my home on concordia [06:20] take 4.4 please [06:20] 4.5 is the playground atm [06:25] Hmm [06:25] desrt: what kernel flavour do you use? [06:25] I thought drivers-acpi-osl_attach-dsdt-to-initrd.dpatch [06:25] was already upstream [06:26] hrm.. external-global-acpi_update.dpatch is pretty *&(^^%_ invasive [06:26] fabbione; 686-smp and powerpc64-smp [06:26] desrt: ok.. i will make 686-smp for you to test [06:26] mjg59_: external-global-acpi_update* were the two you wanted me to pull? [06:27] fabbione; the hardware arrived today for our cluster :) [06:27] fabbione; so, as of tomorrow i'm gonna be running 5 boxes with powerpc64-smp :) [06:28] (and some time later about 12) [06:28] desrt: cool! [06:28] desrt: what kind of cluster are you going to run? [06:28] our own thing [06:29] yeah.. i mean. HA or HP cluster? [06:29] A=Availability [06:29] P=Performance [06:31] lamont__: Yeah [06:31] Anyone have a SuSE kernel source handy? [06:31] I'd love to see if they apply this other one, it's one of their folks that wrote it: [06:32] http://gaugusch.at/acpi-dsdt-initrd-patches/acpi_dsdt_initrd_initramfs.patch [06:32] http://gaugusch.at/acpi-dsdt-initrd-patches/initramfs-before-acpi.patch [06:35] dpkg-deb: building package `linux-image-2.6.12-4-686-smp' in `../linux-image-2.6.12-4-686-smp_2.6.12-4.5_i386.deb'. [06:35] and NO ABI breakage! [06:35] (....yet) [06:35] This too shall pass ;) [06:36] desrt: http://people.ubuntu.com/~fabbione/ [06:37] desrt: there are 3 linux-*-4.5*.deb [06:37] can you test inotify with them? [06:37] they include all the latest fixed [06:37] fixes [06:37] just rememeber that is NOT 4.5 final [06:37] so you might have to upgrade it later === lamont__ watches the whole *&%)_ world rebuild, curses acpi === fabbione goes offline === desrt downloading now [06:50] sorry for the delay. got busy for a moment [06:52] desrt: no problem, take your time to test. [06:52] i need to go out now [06:52] i will bbl [06:53] ps don't use SYSCALLS 289 and 290.. they are fake and unsecure atm [06:53] i already have a better patch done.. [06:53] but i need to know if it works for you now with the 291/292/293 [06:53] in sync with * [06:53] later [06:59] fabbione; problem is not fixed [07:00] :q [07:01] erp [07:26] fabbione; looking at your source package, nothing has changed [07:27] fabbione; (from looking at source) sys_inotify_rm_watch is still doing improper input validation and (from testing against your binary) i'm still getting the crash [07:35] from 2.6.13-rc3-git8: http://manic.desrt.ca/inotify.c [07:35] search for /* verify that this is indeed an inotify instance */ === lamont__ adds external-drivers-ide_sleep to his list, since it's ftbfs without acpi... [07:52] desrt: i didn't put any source there... [07:52] did you take 4.5 ? [07:52] or by mistake you took 4.4? [07:52] i took linux-source-diff that was in the group of them :) [07:52] it's not the one to look at [07:52] ahh [07:52] well, in any case, the binary still exibits the crash :) [07:52] /* verify that this is indeed an inotify instance */ [07:52] this is there [07:52] uname -a shows Jul 27 [07:52] twice [07:53] weird..... [07:53] dpkg -l linux-image-2.6.12-4-686-smp [07:53] 2.6.12-4.5 [07:53] yeah that's it [07:53] want me to send you a testcase? [07:53] it's all the latest inotify [07:54] desrt: did you change the syscalls to match the real ones? [07:54] yes [07:54] i'm using 293 now, i think [07:54] well.. can you recheck please :) [07:55] you're using the same syscall numbers as the official 2.6.13, right? [07:55] also.. did you check that it is fixed in git8? [07:55] yes. right [07:55] no. i haven't. [07:55] by running it... [07:55] well that would be something to do :) [07:55] cool [07:55] 293 is, in fact, the right number [07:56] will test git [07:56] thanks [07:56] ohwee...i got business cards [08:01] man... it's times like this when i'm building a kernel that i wish i had a nice pentium D system === crimsun [~crimsun@crimsun.silver.supporter.pdpc] has joined #ubuntu-kernel [08:02] crimsun; w3rd. [08:03] 'lo desrt === desrt plays a good beatles song to honour your presence [08:04] "nothing's gonna change my world....." === doko [~doko___@dsl-084-059-085-139.arcor-ip.net] has joined #ubuntu-kernel [08:15] fabbione; i get -EINVAL on that syscall on 2.6.13-rc3-git8 [08:15] and no crash [08:16] so 2.6.13-rc3: bad [08:16] so 2.6.13-rc3-git8: good [08:16] and 2.6.12-4.5: bad [08:19] desrt: ok.. i will give you another kernel in a few minutes.. [08:19] :) [08:19] it looks like not all the patches in git as commented as they should... [08:25] desrt: it's building.. [08:26] if this one still crash, i know exactly what it is [08:26] but [08:26] it's not going to be fun at all === smurfix [~smurf@smurfix.developer.debian] has joined #ubuntu-kernel [08:34] desrt; http://people.ubuntu.com/~fabbione/desrt/ <- [08:34] i will be back in few minutes.. [08:54] desrt: ? [08:54] fabbione; just installed and am rebooting now [08:54] cool [08:55] Jul 27 18:25:09 UTC [08:55] no crash [08:55] perfect [08:55] ship it! :) [08:55] do you want to know what it was? [08:55] ya. for sure [08:56] NEVER TRUST PATCH! [08:56] uhm... what happened? [08:56] basically i was doing cg-mkpatch -r $id | patch -d $pathtokernel -p1 [08:56] on all inotify commit [08:56] no rejects [08:56] no fuzzyness [08:56] it ended with 2 different files [08:57] (same base of course) [08:57] like what? [08:57] there were diffs in the order of some hunks [08:58] the final inotify.c was different [08:59] @@ -990,6 +991,8 @@ [08:59] filp = fget_light(fd, &fput_needed); [08:59] if (unlikely(!filp)) [08:59] return -EBADF; [08:59] + dev = filp->private_data; [08:59] + ret = inotify_ignore (dev, wd); [08:59] [08:59] /* verify that this is indeed an inotify instance */ [08:59] if (unlikely(filp->f_op != &inotify_fops)) { [08:59] @@ -997,9 +1000,6 @@ [08:59] goto out; [08:59] } [08:59] [08:59] - dev = filp->private_data; [08:59] - ret = inotify_ignore(dev, wd); [08:59] - [08:59] something like this [08:59] er [08:59] that's the inverse of the patch you need :) [08:59] actually, it's just nonsense [08:59] yes sorry.. [09:00] it's like "do it first, check later" :) [09:00] i did it the wrong way [09:00] but it still landed in the wrong order in the final inotify.c [09:00] that's the point [09:00] nod. [09:00] well [09:00] it all seems to be working fine now [09:00] never mind the direction of that patch [09:00] maybe the cg-mkpatch wasn't generating enough lines of context [09:01] so it just went blindly by linenumber and put it in the wrong place [09:01] possibly [09:01] that'd also explain why it didn't mention any fuzz [09:03] baz commit -s'Update inotify' [09:03] ok. so is this when a bug becomes PENDINGUPLOAD? [09:03] M patches/sth-fs_inotify.dpatch [09:03] M changelog [09:03] yes [09:03] but iirc you can't change from UPSTREAM to PENDINGUPLOAD directly [09:04] so we will close it after we upload... [09:04] not a big deal [09:04] nod. [09:04] jbailey mjg59_: ping? [09:04] pong [09:04] otherwise you need to put it as ASSIGNED and than PENDINGUPLOAD [09:04] ya. evil bugzilla :P [09:04] jbailey: remember i will be VAC from 1st of Aug [09:05] infinity will take care of the kernel [09:05] but i plan an upload for no later than friday [09:05] so if there is something important or urgent, it has to be withing friday morning [09:05] mjg59_: the above is valid also for ACPI [09:05] because the 8th of Aug is Feature Freeze [09:05] (or the 5th.. i can never remember) [09:06] hmmm...i think im going to be busy this weekend ;) [09:06] zul: no crack please.. only tested committs... [09:06] we need to go very stable and very fast [09:06] yep [09:06] zul: specially.. test before commit [09:06] or at least build [09:07] i don't want to come back and have to cleanup a mess :) [09:07] heh... [09:07] all of my group has gone home for the day. and its only 3:13pm [09:08] slackers [09:21] ok [09:21] time to stop [09:21] it's only 9:20 pm [09:21] and i started at 6am [09:22] :) [09:22] fabbione++ [09:22] another 2 bug fixes done.. [09:22] desrt: i might upload tomorrow.. [09:22] or max friday [09:22] you can use the temp kernel in the meanwhile [09:22] it's cool. it's not actually affecting me [09:23] i can just avoid passing an invalid fd to inotify :P [09:23] uh no.. the other 2 bug fixes are ACPI and USB related [09:31] i think we might have to close some more non-responsive user bugs tonight as well [09:33] zul: go ahead [09:33] KILL THEM ALL! [09:33] users or bugs? [09:33] users of course [09:33] both, preferably === fabbione switches to bastart mode [09:33] Mithrandir: why so much blood? [09:33] users are enough [09:33] unresponsive user on bug -> CLOSE [09:34] i need to buy another THX [09:34] after i moved mine in the living room i miss to listen to music in a decent way === fabbione goes offlinw [09:42] there.. i can't even type anymore... [09:49] unresponsive user on bug -> CLOSE [09:49] i need to buy another THX [09:49] buy another user? [09:49] Dude, you don't PAY for those. [09:49] They come free. =0 [09:49] =) === Mithrandir tickles the man with blue streaks in his hair. [10:01] Mithrandir: who went tropical-fish on us? [10:02] lamont__: http://www.raspberryginger.com/jbailey/weblog/entries/photos/hpim2587.jpg [10:02] Mithrandir: eh... =) [10:02] Mithrandir: I'm *not* adding a highlight on "blue". That would be a bit too much. =) [10:02] jbailey: you need more elmers glue. [10:03] lamont__: Err. Why? [10:03] jbailey: looks nice, though [10:03]