[00:04] morning kernelonauts [00:06] morning jk [03:22] Please help. What is wrong with the kernel headers? I can't build VMWare modules. [03:22] on Maverick [03:23] Linux 2.6.35-24-generic #42-Ubuntu SMP Thu Dec 2 01:41:57 UTC 2010 i686 GNU/Linux [03:27] it's been a while since i tried to buuld vmwares modules; but something changed regarding iommu stuff [03:27] regarding what? [03:28] iommu stuff. [03:29] never heard of it [03:29] something diverged from what their shim did in the kernel [03:29] The directory of kernel headers (version @@VMWARE@@ UTS_RELEASE) does not match [03:29] your running kernel (version 2.6.35-24-generic). Even if the module were to [03:29] compile successfully, it would not load into the running kernel. [03:32] ah, that's different from what happened last time i tried, then === bjf is now known as bjf[afk] [08:31] * apw looks blearily out at the world, "and it was dark" [08:36] * amitk turns on the light in apw's office [08:36] * lag shines a light and is taken aback to see apw still has his sleeping blindfold on [08:36] Bugger [08:36] heh [08:36] Pipped [08:37] apw: What do you know about APIC? [08:38] hey apw, lag & amitk [08:38] Morning jk- :) [08:38] morning all [08:39] lag some, what you want to know [08:39] Why my Dad's computer went pop when I installed Ubuntu [08:39] jk-: hiya [08:40] Not a good thing when introducing it as the best thing since sliced bread [08:40] apw: bug 697121 [08:40] Launchpad bug 697121 in linux (Ubuntu) "Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with apic=debug and send a report. Then try booting with the 'noapic' option (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/697121 [08:44] "the best thing since sliced bread" so true :D === smb` is now known as smb [08:50] lag, what sort of machine is it? [08:50] Desktop - HP IIRC [08:51] doesn't seem to be any machine info, i believe the machine booted from a livecd ok ? [08:52] so could we get some machine info from it? [08:52] mourning everybody [08:52] lag, as we installed generic, does the CD kernel boot? [08:53] morning smb [08:53] * smb definitely mourns on unity. Seems to be a new behaviour evry boot [08:54] smb, yeah its currently a BOA [08:54] BOA, eh? [08:54] bag-of-ass [08:54] pants [08:54] * diwic was guessing on "Bag Of Asbest" [08:54] you crazy brits with your bags of things [08:55] i think its mostly me :) [08:55] :) [08:55] I like to make grossly inaccurate assumptions on small sample sizes [08:55] Three slightly different entries in applications to manage files "file browser", "file management" and "file manager" and none to change the date and time. \o/ [08:56] click on the clock maybe? [08:56] or do some other gesture to the clock? :) [08:56] hold it upside-down and shake it, etch-a-sketch style [08:56] That *would* be the common thing, except that it is there but not clickable [08:57] apw: All machine info is available from the other bug [08:57] clock basically has no controls ... can't even get european/military time option, or indeed the date displayed [08:57] lag then the bug should say so :) [08:57] apw: The other bug is mentioned in the description [08:58] apw: No, it didn't boot from the LiveCD okay [08:58] Morning smb [08:58] lag, morning [08:58] as for the fact that chromium being my default browser and it starting firefox for everything ... BOA indeed [08:58] and apw jk- and whoelse is up complaining thing morning. :) [08:59] plus we have 3 whole days to get something we can use on the road before i have to scratch this heap to hardy [08:59] apw, Hardy? [08:59] smb, dapper perhaps ? [09:00] I am actually happy enough with Lucid [09:00] Dapper might give you some slight problems as most of the "modern" network devices would not work [09:00] smb, heh indeed [09:01] lag, so no from that, no specific ideas off the top of my head, smb has some knowledge of apics [09:01] Though I must admit the boot screen looks actually neater to me. :-O [09:01] apw, lag Not got that far in the backlog [09:01] what are we talking about [09:02] found it [09:02] smb, boto screen in natty ? [09:03] apw speaks in riddles this morning [09:03] smb, apw: I understand it can be a BOIS issue, but there are no BIOS updates - kernel still shouldn't panic [09:03] lag, I think cking will run screaming if you mention HP laptops to him [09:04] smb: It's not a laptop :) [09:04] HP desktop? Even worse. :-P [09:04] I ran the FWTS on it, all checked out fine [09:04] don't mention BIOS to me so early in the morning [09:05] smb, you said you liked the boot screen, i was wondering which one, was it natty's ? [09:05] cking: Help me damn it! ;) [09:06] lag, I came in a bit late on the discussion. Wassup? [09:06] lag, well sometimes we have no choice when we have no idea what to do with the heap the bios has left [09:06] apw, I said something about a boot screen? [09:06] Must have been gnarl and now hiding [09:06] Though I must admit the boot screen looks actually neater to me. :-O [09:06] apw: Windows works flawlessly - and that's all these people see (and say) [09:06] apw, Oh ah, there I was referencing to Dapper [09:07] cking: bug 697121 [09:07] Launchpad bug 697121 in linux (Ubuntu) "Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with apic=debug and send a report. Then try booting with the 'noapic' option (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/697121 [09:07] I obviously need more coffee [09:07] lag, indeed they probabally do ... and though its a valid point, it is utterly unhelpful to us [09:07] if you supply the machine specific part of the OS with a machine is somewhat more likely to work [09:08] apw, smb, cking, amitk, jk-: http://i173.photobucket.com/albums/w80/ljkenny/Tilly-1.jpg [09:08] lag, had a baby ? [09:08] lol [09:09] apw: Yes [09:09] apw: Tilly! [09:09] She's asleep on my lap currently :) [09:09] heh that or get married huh ? [09:09] apw, a puppy will put of a baby request for 18 months [09:09] I made my choice [09:09] s/of/off/ [09:09] cking, indeed [09:09] cking: Bingo! [09:10] cking, yeah this way he has 12 months to get the marriage in [09:10] So not getting married :) [09:11] The puppy is to keep my company during the day [09:11] apw, But back to that bug. As the installer boots, upstream probably broke something in between [09:11] Christ knows what we're going to do for sprints though! [09:11] lag, did the installer work ? [09:11] apw: No [09:11] lag, her problem :) [09:11] lag, you don't come to sprints any more anyhow [09:12] apw: Only with noacpi and the internal card reader un-socketed [09:12] what did apic=debug produce? [09:12] apw: Not true - only missing one [09:12] lag, Then that description in the bug is heavily misleading [09:12] cking: Same result [09:12] cking: Read the bug dammit ;) [09:12] smb, i know ... hopeless :) [09:12] lag: cute, how does she get along with the reptiles? [09:12] oh ya [09:13] amitk: We have a two intermediary door rule [09:15] apw, I have no clue about the versions in natty... but is 2.6.35-23 not a bit old? [09:16] * smb thinks we need to educate this Lee guy about proper bug report information [09:17] somebody has a broken BIOS and/or APIC/cascaded ExtINTA config :-) [09:18] smb -security for maverick [09:19] apw, Yeah, I could have guessed after you added the Maverick tag [09:19] Just not clear at all from the rest of the info [09:19] Nor whether Lucid had worked [09:19] Or anything else useful [09:19] lag, yeah we might want to try an lucid live CD and see if that boots ok [09:21] And it would be good to have dmesg (even with noapic), dmidecode and maybe acpidump too [09:21] lag, hrm, with apic=debug you should see quite a bit of APIC debug, so perhaps the kernel param "loglevel" needs to be set to print more info [09:21] apw: I tried - same result [09:21] cking: Perhaps [09:21] lag, heh well it would help if you recorded some of your history then [09:22] save us all asking you the same things over and over [09:22] I can't do anything at the moment though, as the machine is in Essex [09:22] the debug will then dump out pin settings and we can then figure out how broken the BIOS config is :-) [09:22] cking, Could be it explodes before getting that far [09:23] smb, the panic message comes at the end of the APIC config, and the code dumps out the config settings before this panic message [09:23] * smb wonders whether this hw could have multiple nodes/apics or so [09:24] yep, dumping the APIC tables is useful too. So including output from acpidump could be instructive [09:24] apic=debug show_lapic=all may be useful too [09:25] just my 2 cents worth [09:25] where was I...? [09:26] * cking goes back to checking email [09:26] It was so quiet and peaceful yesterday, when UK was on holiday... ;-P [09:26] :-) [09:30] cking: I'll have to give it a bash when I go back home [09:30] with a hammer? [09:30] cking: Do you think bug 695274 could be related (when I use 'noapic') [09:30] Launchpad bug 695274 in linux (Ubuntu) "WARNING: at /build/buildd/linux-2.6.35/net/sched/sch_generic.c:258 dev_watchdog+0x1fd/0x210() (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/695274 [09:36] ubot2, hmm. I think there was just a commit in linuses tree about this [09:36] czr: Error: I am only a bot, please don't think I'm intelligent :) [09:36] bleh :-). [09:36] ah no. not that one. [09:46] lag, perhaps acpi_skip_timer_override may help, I've seen this required for some HP laptops [09:47] cking: It may well do, but I have no way of testing that ATM, as the computer is in Essex [09:50] sure, just throwing in some ideas [10:53] morning [10:53] can someone help me with bug 682681? [10:53] Launchpad bug 682681 in linux (Ubuntu) "allow to build linux-source package only (affects: 1) (heat: 124)" [Undecided,In progress] https://launchpad.net/bugs/682681 [10:57] hrw, i thought we already had support for early builds like that [10:58] hrw, via the stage stuff? [11:00] apw: this is similar. I just noticed that I need to update patch in bug to show what I need [11:01] apw: the idea is "provide PPA with cross toolchain backports" and I need a way to get linux-2.6.37-source package without any other packages built [11:01] hrw, i am confused as to why the stage1 is not needing the same thing [11:02] as the purpose of stage1 is to generate "what you need to boot strap the compilers" [11:02] ok, let me then explain [11:02] which sounds exactly what you are doing [11:03] stage1 support allows me to generate linux-libc-dev package but also generates few others which I just do not care about. BACKPORT patch adds a way to build linux-source only (will follow with patch to generate linux-VER-source instead of linux-source). [11:04] results of stage1 build are not available to user during my cross-toolchain builds because I use just one package from it (linux-libc-dev) which I mangle to linux-libc-dev-armel-cross one (available later for user) [11:05] BACKPORT build will result in only linux-VER-source package which will be put in PPA and then used by me to build linux-libc-dev-armel-cross for cross toolchain backport [11:05] hrw, well it sounds like it should be a DEB_STAGE to me, perhaps "sourceonly" ? [11:06] if I would have to support maverick+ I would not need this but I have to cover lucid ;( [11:06] though how are you setting 'BACKPORT' anyhow? [11:06] apw: source package pushed into PPA will have BACKPORT=true hardcoded [11:07] so why can't you just hardcode the do_xxx options [11:07] right ;) [11:08] apw: I prepared such patches for gcc/eglibc/binutils and then made one also for linux - but you have right - it can be just kept locally [11:09] it sounds like you have to patch *.mk anyhow to add backports so you can just hardcode the do_'s ... so its not obvious how useful having the change in tree is ... [11:09] but if you think its easier to maintain if we carry some option, i think DEB_STAGE=sourceonly or similar might make more sense than a new variable [11:09] ok [11:10] as DEB_STAGE already modifies the package sets we pop out [11:11] * apw has to admit he has been thinking about making many of the do_ variables automatically set from the control file contents at build time [11:11] as they have to match === diwic is now known as diwic_afk === diwic_afk is now known as diwci === diwci is now known as diwic [12:58] apw, what about the omap3 kernels, i would like to enable omap3 builds this week and iirc we're waiting for a kernel team decision [13:04] * apw__ waves [13:05] from the waves? :) [13:06] heh not far off it indeed [13:19] * apw__ notes just how quiet it is today [13:25] * smb notes just how quiet it was yesterday. :-P [13:32] ogra, i think your testing rejected the kernels from master branch as unbootable [13:45] huh ? [13:45] when was that ? [13:46] all i know is that we extensively tested the linaro kernels before the holidays [13:46] and that they were good [13:46] ogra, right, and noone is stepping up to support those as i understand it [13:46] so we need to revert to the maverick state [13:47] there is no direction that we want to support arm omap3 at all currently [13:47] i.e. to a supported set [13:47] there is [13:47] ogra, from where [13:47] omap3 has the biggest community [13:47] we dont want to lose them [13:47] that is desire, not direction though [13:47] its the only way to get enough developers to work with us [13:48] omap3 was never "officially supported" [13:48] well that community could be served with linaro kernel then isn't it ? [13:48] so i dont get why we need to change behavior now [13:48] ogra, cause we lost all of our arm engineers ? [13:48] they will use linaro hwpacks [13:48] not ubuntu images [13:49] then why do we even need ubuntu images, if they are using hwpacks from linaro ? [13:49] losing omap3 would be the worst that could happen for the arm project [13:49] linaro users will use linaro hwpacks [13:49] not ubuntu images [13:50] so the one big community we can have (amd have supported up to now with "unsupported images") will be lost [13:50] we will lose all desktop and userspace testing then [13:51] not to talk about the other flavours, it took us several releases to have something for the kubuntu and xubuntu communities [13:51] so they can work on their stuff on affordable HW [13:51] ogra, thats all very accurate i am sure, but the reality is we currently don't have resourece to support another kernel [13:52] natty was supposed to be the first release to offer them prebuilt images (based on omap3 from us and based on imx51 from a community project) [13:52] we dont have the resources to just re-enable the maverick status in the kernel package ? [13:52] sorry but i dont get that [13:53] do you know that the maverick kernel works in natty ? [13:53] i'm talking about the packaging [13:53] not the tree [13:53] ogra, you mean enabling the omap build in the master branch of natty ? [13:53] what would have happened if i hadnt offered to switch to linaro kernels ? [13:54] yes, thats what i mean [13:54] ogra, likely you'd have no kernels at all for omap3 ... [13:54] huh ? [13:54] but ... i tried enabling omap3 at the end of last year [13:54] and you tested it and rejected it [13:54] huh ? [13:54] can you please point me to any conversation about that ? [13:54] all we tested was linaro packages [13:55] at end end of last year (2010) i asked you to test some kernels i made from natty master [13:55] and GrueMaster reported that it was no good [13:55] sigh [13:55] i can make you some more from todays tip if that helps [13:56] that might help though i dont want to waste your time, let me talk to GrueMaster first [13:56] ogra, but i have no h/w to test/debug them so i am relaiant on smeone to test [13:56] indeed [13:56] cirtainly if omap3 is coming for free out of master we are more able to support you in this endevour [13:57] right, i dont see any difference to maverick here [13:57] the linaro thing was an experiment to make your life easier [13:58] ogra, well we dropped omap3 from master on your request [13:58] so i'm a bit sad to see resistance to revert to the former state ... though if there are technical blockers in the mainline tree (which surprises me since it worked before) the arm team should make sure to sort them for you [13:58] yes [13:59] because i didnt want to have two kernels in main [13:59] ogra, and thats how we eneded up here [13:59] i know [13:59] with the thought that i wanted to put load off the kernel teams sholders [14:10] sforshee, yo ... welcome [14:11] ditto [14:22] apw, echo "do_tools=false dpkg-buildpackage -aarmel -nc -uc -us"|schroot -c maverick-amd64 === smb` is now known as smb [14:50] bouncy smagoun [14:50] BA [14:50] bouncy smb [14:51] was that a threat or a proposition? :) [14:51] smagoun, heh, the threat was to IRC for being soooo annoying and picking the wrong nick ... :) [14:57] and using anything start sm when you hit tab. :) === diwic is now known as diwic_afk === smoser` is now known as smoser [15:07] sforshee, do you know about the team meeting today at 17:00UTC ? [15:10] sforshee, its in #ubuntu-meeting in about 1:50 from now [15:13] apw: how are you building the omap 3 package? can you point me the config file you're using? [15:14] apw: then I can help trying to identify why it's not booting on my omap 3 hardware [15:14] since last time GrueMaster tested it basically didn't boot [15:14] rsalveti, the one i am trying to test i am building out of the natty master branch, i'll get the config up onto pastebin or something [15:14] apw: cool, thanks [15:15] rsalveti, yeah that was my memory, 'no good' but no real details as to any issues [15:16] yeah [15:16] theoretically the code shouldnt have changed to much [15:16] so if the config is identical to maverick it should technically work [15:16] not exactly [15:16] ogra, indeed, though the config of the kernel overall has gone through the wringer [15:16] but I can also compare with linaro's config [15:17] so its entirly possible things got lost, plus a bunch of omap patches dropped out as they collided [15:17] ah, so omap might inherit some x86 setting it burps on [15:17] indeed so [15:18] rsalveti, i'll have latest images to test and the config together and up in a few [15:18] apw: thanks [15:19] rsalveti, does linaro have a .37 config even thought? [15:19] though [15:19] apw: I'm just cloning their tree, but they are using .37 already, so the config should be working fine for them [15:26] rsalveti, http://people.canonical.com/~apw/omap3-natty/ [15:26] ogra, ok latest omap3 kernels are at the URL above ^^ === bjf[afk] is now known as bjf [15:27] thanks [15:30] apw: thanks, will give it a try === hito_jp0 is now known as hito_jp [15:31] ## [15:31] ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting [15:31] ## agenda: https://wiki.ubuntu.com/KernelTeam/Meeting [15:31] ## [15:41] apw, have you seen bug #693042 ? [15:41] Launchpad bug 693042 in linux (Ubuntu) "Kernel Panic while booting Natty installer kernel (2.6.37-10-generic) on amd64 ISO (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/693042 [15:43] tgardner, /me looks [15:44] tgardner, thats on an old kernel, but interesting its just -server ... will ask them to test the latest [15:46] tgardner, actually that appears to be init exiting [15:46] so that may not be a kernel issue, we did get updates to upstart too around then [15:47] apw, ack. ara was hassling bladernr about it [15:48] tgardner, apw may be, that was back in mid-dec. if updates to everything have rolled into new ISOs since then it may not be an issue any longer...those issues were during netbooting [15:49] we're ggetting ready to start ISO testing again this week, so I'll see if there are still issues [15:49] bladernr, cool. hassle us on IRC if the issue persists [15:49] bladernr, yeah, it looks like we swizzled into userspace in the initramfs and then the init in there just exited ... not sure who would be to blame there [15:49] I blame fader [15:50] hrmmm... or JFo, he's too far away to do anything to me right now [15:50] :-) [15:50] I'll update it as soon as I know something... hopefully today or tomorrow depending on what I get roped into [15:51] bladernr, yeah let us know, we are bound to forget [15:51] tgardner, thanks [15:52] apw, delegation is my specialty [15:52] :) [16:07] bladernr, sorry, was looking at the other computer screen :-) [16:08] JFo: nevermind... we got it sorted [16:08] smb, around ? [16:08] JanC: don't need you no how ;-) [16:08] bladernr, cool [16:08] errr... JFo not JanC [16:08] smoser, yep [16:08] lol [16:08] smoser, Oh, guess I forgot the server meeting [16:09] i'm gonna launch a cluster compute instance to verify that it doesn't have ephemeral disks attached, then let you poke around if you have some time (and yeah, server meeting also) [16:09] (i plan to leave it up for only 1 hour) [16:12] smoser, You probably assume I know what you want me to do... Though with the end of year erasure this is kind of optimistic. You'd best remind me of what I should look for. Also, with the server team meeting up and the kernel team meeting following right after I am not sure there will be much poking time [16:12] smb, yeah, i would fill you in. [16:13] smb, would you rather i wait till after those 2 ? [16:13] i'll send you a mail [16:14] smoser, That would be good. After those I should be less disctracted. [16:14] k. [16:23] smb, for later, http://pad.daviey.com/Y6LhDy2gMd . please take a read, and ping me when you have some time. i'll launch 2 instances (one amazon/centos, one natty) and open a bug from the natty, then give you access. [16:26] smoser, k, will do === jepler- is now known as jepler [16:31] ## [16:31] ## Kernel team meeting in 30 minutes [16:31] ## [16:58] * tgardner is sure jjohansen is going to report progress on ecryptfs during the kernel team meeting in 3 minutes. [16:58] tgardner: yep :) [16:59] ## [16:59] ## Meeting starting now [16:59] ## [17:28] It seems to me that kernel bugs regarding package installation issues, tagged apport-package, shouldn't be tagged needs-upstream-testing [17:29] bdmurray, doesn't seem reasonable, does it? [17:30] tgardner: nope, not really [17:30] is that a tag that apport applies? [17:31] or something one of JFo's scripts did? [17:31] i think it happens in the apport hooks actually [17:31] tgardner: which for the kernel is a part of the apport package. I could likely fix it. [17:32] bdmurray, yeah, packaging problems definitely don't need upstream testing :) [17:32] yeah, I want to get some time at platform to look at the apport hook [17:33] there is much to be done there [17:33] apw, don't think it's apport, i think its our arsenal scripts [17:33] bdmurray, tgardner, JFo ^ [17:33] I'm sure those need adjustment as well [17:33] bjf: well bug 696149 has both tags and hasn't be arsenal'ed [17:33] Launchpad bug 696149 in linux (Ubuntu) "package linux-image-2.6.35-22-generic 2.6.35-22.35 failed to install/upgrade: subprocess installed post-installation script returned error exit status 2 (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/696149 [17:33] can we look at both during the rally? [17:33] or is our time filled already? [17:33] bjf, it is likely both, but i am pretty sure we put it on in apport after asking if they have tested upstream [17:33] smoser, ok so meetings are done for today. So it is the devices not showing up problem to be looked at? [17:34] JFo, yes we should, we should get it on agenda [17:34] k [17:34] apw, done [17:35] thanks tgardner [17:41] smb, yeah. let me start some instances. [17:42] there are some comments in bug 539467 indicating that isn't fixed [17:42] Launchpad bug 539467 in pm-utils-powersave-policy (Ubuntu Lucid) (and 6 other projects) "SATA link power management causes disk errors and corruption (affects: 23) (heat: 150)" [Undecided,Fix released] https://launchpad.net/bugs/539467 [17:45] hm, I thought the fix was to remove the script that enables pm for the disk controller. which was done... I thought. Though it has been some time [17:45] smb, the fix for PM was only done in lucid [17:45] and the kernel was slated to be fixed in maverick [17:45] but an upstream change [17:46] smb, i suspect we now need a maverick nom so we can separate that from natty [17:46] apw, Something on link powermanagement or that magic thing for via controllers and wd disks? [17:47] hm, yes sounds like a sensible approach for maverick at least [17:47] smb, i have not seens the specifics of the fix only see it mentioned, and that was why there was no fix for pm-utils-* [17:47] and then "fix" pm-utils again [17:48] smb, ok done [17:51] smb, ok commentary added as to why i've done what i've done [17:51] smb, are you looking after that one? [17:51] apw, not really actively until now at least... [17:51] JFo, does kernel-key work yet? will they appear on the list ? [17:52] apw: did you hit an issue with the AA compatibility patches not applying? [17:52] jjohansen, not that i've noticed so far [17:52] apw: okay, if you do let me know [17:53] jjohansen, i have three patches by the looks of things [17:53] * jjohansen needs to fix them for 2.6.32.2 [17:53] sorry 4 [17:53] UBUNTU: SAUCE: AppArmor: Fix unpack of network tables. [17:53] yeah that sounds right [17:53] AppArmor: compatibility patch for v5 interface [17:53] AppArmor: compatibility patch for v5 network controll [17:53] UBUNTU: SAUCE: AppArmor: Allow dfa backward compatibility with broken usersp [17:54] jjohansen, they apply ok to 37-rc8 [17:54] apw: yeah interesting /me needs to look into why they are working on .37 and failing on .36.2 [17:57] smb, ok. so i'm going to launch instances [17:57] sorry for delay [17:58] smoser, no worries. [17:59] jjohansen, they have been rebased through each -rc so perhaps they got fixed by that as they went [17:59] apw: yeah that is my assumption [17:59] apw, rebased against Linus tip and am rerunning stress on Urbana. Still up after 55 minutes. [17:59] though its supprising that .2 has anything big [18:00] tgardner, so thats between -rc8 and tip has helped for you ? [18:00] apw, seems to have. absense of evidence (and all that) ... [18:00] apw: it doesn't, its a small fix but enough to cause the out of tree compatibility patches to fail [18:00] tgardner, modulo not knowing how reproducible it is [18:00] apw, yep. there were a couple of core mem fixes since -rc8 [18:01] though I didn't look very close [18:01] there is a 'wrong VM_BUG_ON()' which might be the trigger [18:01] thats what I was thinking about [18:02]