| jk- | morning kernelonauts | 00:04 |
|---|---|---|
| jjohansen | morning jk | 00:06 |
| lucmove | Please help. What is wrong with the kernel headers? I can't build VMWare modules. | 03:22 |
| lucmove | on Maverick | 03:22 |
| lucmove | Linux 2.6.35-24-generic #42-Ubuntu SMP Thu Dec 2 01:41:57 UTC 2010 i686 GNU/Linux | 03:23 |
| ohsix | it's been a while since i tried to buuld vmwares modules; but something changed regarding iommu stuff | 03:27 |
| lucmove | regarding what? | 03:27 |
| ohsix | iommu stuff. | 03:28 |
| lucmove | never heard of it | 03:29 |
| ohsix | something diverged from what their shim did in the kernel | 03:29 |
| lucmove | The directory of kernel headers (version @@VMWARE@@ UTS_RELEASE) does not match | 03:29 |
| lucmove | your running kernel (version 2.6.35-24-generic). Even if the module were to | 03:29 |
| lucmove | compile successfully, it would not load into the running kernel. | 03:29 |
| ohsix | ah, that's different from what happened last time i tried, then | 03:32 |
| === bjf is now known as bjf[afk] | ||
| * apw looks blearily out at the world, "and it was dark" | 08:31 | |
| * 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 | |
| lag | Bugger | 08:36 |
| amitk | heh | 08:36 |
| lag | Pipped | 08:36 |
| lag | apw: What do you know about APIC? | 08:37 |
| jk- | hey apw, lag & amitk | 08:38 |
| lag | Morning jk- :) | 08:38 |
| apw | morning all | 08:38 |
| apw | lag some, what you want to know | 08:39 |
| lag | Why my Dad's computer went pop when I installed Ubuntu | 08:39 |
| amitk | jk-: hiya | 08:39 |
| lag | Not a good thing when introducing it as the best thing since sliced bread | 08:40 |
| lag | apw: bug 697121 | 08:40 |
| ubot2 | 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:40 |
| akheron | "the best thing since sliced bread" so true :D | 08:44 |
| === smb` is now known as smb | ||
| apw | lag, what sort of machine is it? | 08:50 |
| lag | Desktop - HP IIRC | 08:50 |
| apw | doesn't seem to be any machine info, i believe the machine booted from a livecd ok ? | 08:51 |
| apw | so could we get some machine info from it? | 08:52 |
| smb | mourning everybody | 08:52 |
| apw | lag, as we installed generic, does the CD kernel boot? | 08:52 |
| apw | morning smb | 08:53 |
| * smb definitely mourns on unity. Seems to be a new behaviour evry boot | 08:53 | |
| apw | smb, yeah its currently a BOA | 08:54 |
| jk- | BOA, eh? | 08:54 |
| apw | bag-of-ass | 08:54 |
| apw | pants | 08:54 |
| * diwic was guessing on "Bag Of Asbest" | 08:54 | |
| jk- | you crazy brits with your bags of things | 08:54 |
| apw | i think its mostly me :) | 08:55 |
| jk- | :) | 08:55 |
| jk- | I like to make grossly inaccurate assumptions on small sample sizes | 08:55 |
| smb | 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:55 |
| jk- | click on the clock maybe? | 08:56 |
| jk- | or do some other gesture to the clock? :) | 08:56 |
| jk- | hold it upside-down and shake it, etch-a-sketch style | 08:56 |
| smb | That *would* be the common thing, except that it is there but not clickable | 08:56 |
| lag | apw: All machine info is available from the other bug | 08:57 |
| apw | clock basically has no controls ... can't even get european/military time option, or indeed the date displayed | 08:57 |
| apw | lag then the bug should say so :) | 08:57 |
| lag | apw: The other bug is mentioned in the description | 08:57 |
| lag | apw: No, it didn't boot from the LiveCD okay | 08:58 |
| lag | Morning smb | 08:58 |
| smb | lag, morning | 08:58 |
| apw | as for the fact that chromium being my default browser and it starting firefox for everything ... BOA indeed | 08:58 |
| smb | and apw jk- and whoelse is up complaining thing morning. :) | 08:58 |
| apw | 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 |
| smb | apw, Hardy? | 08:59 |
| apw | smb, dapper perhaps ? | 08:59 |
| smb | I am actually happy enough with Lucid | 09:00 |
| smb | Dapper might give you some slight problems as most of the "modern" network devices would not work | 09:00 |
| apw | smb, heh indeed | 09:00 |
| apw | lag, so no from that, no specific ideas off the top of my head, smb has some knowledge of apics | 09:01 |
| smb | Though I must admit the boot screen looks actually neater to me. :-O | 09:01 |
| smb | apw, lag Not got that far in the backlog | 09:01 |
| smb | what are we talking about | 09:01 |
| smb | found it | 09:02 |
| apw | smb, boto screen in natty ? | 09:02 |
| smb | apw speaks in riddles this morning | 09:03 |
| lag | smb, apw: I understand it can be a BOIS issue, but there are no BIOS updates - kernel still shouldn't panic | 09:03 |
| smb | lag, I think cking will run screaming if you mention HP laptops to him | 09:03 |
| lag | smb: It's not a laptop :) | 09:04 |
| smb | HP desktop? Even worse. :-P | 09:04 |
| lag | I ran the FWTS on it, all checked out fine | 09:04 |
| cking | don't mention BIOS to me so early in the morning | 09:04 |
| apw | smb, you said you liked the boot screen, i was wondering which one, was it natty's ? | 09:05 |
| lag | cking: Help me damn it! ;) | 09:05 |
| cking | lag, I came in a bit late on the discussion. Wassup? | 09:06 |
| apw | lag, well sometimes we have no choice when we have no idea what to do with the heap the bios has left | 09:06 |
| smb | apw, I said something about a boot screen? | 09:06 |
| smb | Must have been gnarl and now hiding | 09:06 |
| apw | <smb> Though I must admit the boot screen looks actually neater to me. :-O | 09:06 |
| lag | apw: Windows works flawlessly - and that's all these people see (and say) | 09:06 |
| smb | apw, Oh ah, there I was referencing to Dapper | 09:06 |
| lag | cking: bug 697121 | 09:07 |
| ubot2 | 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 |
| smb | I obviously need more coffee | 09:07 |
| apw | lag, indeed they probabally do ... and though its a valid point, it is utterly unhelpful to us | 09:07 |
| apw | if you supply the machine specific part of the OS with a machine is somewhat more likely to work | 09:07 |
| lag | apw, smb, cking, amitk, jk-: http://i173.photobucket.com/albums/w80/ljkenny/Tilly-1.jpg | 09:08 |
| apw | lag, had a baby ? | 09:08 |
| smb | lol | 09:08 |
| lag | apw: Yes | 09:09 |
| lag | apw: Tilly! | 09:09 |
| lag | She's asleep on my lap currently :) | 09:09 |
| apw | heh that or get married huh ? | 09:09 |
| cking | apw, a puppy will put of a baby request for 18 months | 09:09 |
| lag | I made my choice | 09:09 |
| cking | s/of/off/ | 09:09 |
| apw | cking, indeed | 09:09 |
| lag | cking: Bingo! | 09:09 |
| apw | cking, yeah this way he has 12 months to get the marriage in | 09:10 |
| lag | So not getting married :) | 09:10 |
| lag | The puppy is to keep my company during the day | 09:11 |
| smb | apw, But back to that bug. As the installer boots, upstream probably broke something in between | 09:11 |
| lag | Christ knows what we're going to do for sprints though! | 09:11 |
| apw | lag, did the installer work ? | 09:11 |
| lag | apw: No | 09:11 |
| apw | lag, her problem :) | 09:11 |
| apw | lag, you don't come to sprints any more anyhow | 09:11 |
| lag | apw: Only with noacpi and the internal card reader un-socketed | 09:12 |
| cking | what did apic=debug produce? | 09:12 |
| lag | apw: Not true - only missing one | 09:12 |
| smb | lag, Then that description in the bug is heavily misleading | 09:12 |
| lag | cking: Same result | 09:12 |
| lag | cking: Read the bug dammit ;) | 09:12 |
| apw | smb, i know ... hopeless :) | 09:12 |
| amitk | lag: cute, how does she get along with the reptiles? | 09:12 |
| cking | oh ya | 09:12 |
| lag | amitk: We have a two intermediary door rule | 09:13 |
| smb | apw, I have no clue about the versions in natty... but is 2.6.35-23 not a bit old? | 09:15 |
| * smb thinks we need to educate this Lee guy about proper bug report information | 09:16 | |
| cking | somebody has a broken BIOS and/or APIC/cascaded ExtINTA config :-) | 09:17 |
| apw | smb -security for maverick | 09:18 |
| smb | apw, Yeah, I could have guessed after you added the Maverick tag | 09:19 |
| smb | Just not clear at all from the rest of the info | 09:19 |
| smb | Nor whether Lucid had worked | 09:19 |
| smb | Or anything else useful | 09:19 |
| apw | lag, yeah we might want to try an lucid live CD and see if that boots ok | 09:19 |
| smb | And it would be good to have dmesg (even with noapic), dmidecode and maybe acpidump too | 09:21 |
| cking | 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 |
| lag | apw: I tried - same result | 09:21 |
| lag | cking: Perhaps | 09:21 |
| apw | lag, heh well it would help if you recorded some of your history then | 09:21 |
| apw | save us all asking you the same things over and over | 09:22 |
| lag | I can't do anything at the moment though, as the machine is in Essex | 09:22 |
| cking | the debug will then dump out pin settings and we can then figure out how broken the BIOS config is :-) | 09:22 |
| smb | cking, Could be it explodes before getting that far | 09:22 |
| cking | 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:23 | |
| cking | yep, dumping the APIC tables is useful too. So including output from acpidump could be instructive | 09:24 |
| cking | apic=debug show_lapic=all may be useful too | 09:24 |
| cking | just my 2 cents worth | 09:25 |
| cking | where was I...? | 09:25 |
| * cking goes back to checking email | 09:26 | |
| smb | It was so quiet and peaceful yesterday, when UK was on holiday... ;-P | 09:26 |
| cking | :-) | 09:26 |
| lag | cking: I'll have to give it a bash when I go back home | 09:30 |
| cking | with a hammer? | 09:30 |
| lag | cking: Do you think bug 695274 could be related (when I use 'noapic') | 09:30 |
| ubot2 | 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:30 |
| czr | ubot2, hmm. I think there was just a commit in linuses tree about this | 09:36 |
| ubot2 | czr: Error: I am only a bot, please don't think I'm intelligent :) | 09:36 |
| czr | bleh :-). | 09:36 |
| czr | ah no. not that one. | 09:36 |
| cking | lag, perhaps acpi_skip_timer_override may help, I've seen this required for some HP laptops | 09:46 |
| lag | cking: It may well do, but I have no way of testing that ATM, as the computer is in Essex | 09:47 |
| cking | sure, just throwing in some ideas | 09:50 |
| hrw | morning | 10:53 |
| hrw | can someone help me with bug 682681? | 10:53 |
| ubot2 | 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:53 |
| apw | hrw, i thought we already had support for early builds like that | 10:57 |
| apw | hrw, via the stage stuff? | 10:58 |
| hrw | apw: this is similar. I just noticed that I need to update patch in bug to show what I need | 11:00 |
| hrw | 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 |
| apw | hrw, i am confused as to why the stage1 is not needing the same thing | 11:01 |
| apw | as the purpose of stage1 is to generate "what you need to boot strap the compilers" | 11:02 |
| hrw | ok, let me then explain | 11:02 |
| apw | which sounds exactly what you are doing | 11:02 |
| hrw | 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:03 |
| hrw | 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:04 |
| hrw | 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 |
| apw | hrw, well it sounds like it should be a DEB_STAGE to me, perhaps "sourceonly" ? | 11:05 |
| hrw | if I would have to support maverick+ I would not need this but I have to cover lucid ;( | 11:06 |
| apw | though how are you setting 'BACKPORT' anyhow? | 11:06 |
| hrw | apw: source package pushed into PPA will have BACKPORT=true hardcoded | 11:06 |
| apw | so why can't you just hardcode the do_xxx options | 11:07 |
| hrw | right ;) | 11:07 |
| hrw | 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:08 |
| apw | 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 |
| apw | 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 |
| hrw | ok | 11:09 |
| apw | as DEB_STAGE already modifies the package sets we pop out | 11:10 |
| * 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 | |
| apw | as they have to match | 11:11 |
| === diwic is now known as diwic_afk | ||
| === diwic_afk is now known as diwci | ||
| === diwci is now known as diwic | ||
| ogra | 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 | 12:58 |
| * apw__ waves | 13:04 | |
| smb | from the waves? :) | 13:05 |
| apw__ | heh not far off it indeed | 13:06 |
| * apw__ notes just how quiet it is today | 13:19 | |
| * smb notes just how quiet it was yesterday. :-P | 13:25 | |
| apw | ogra, i think your testing rejected the kernels from master branch as unbootable | 13:32 |
| ogra | huh ? | 13:45 |
| ogra | when was that ? | 13:45 |
| ogra | all i know is that we extensively tested the linaro kernels before the holidays | 13:46 |
| ogra | and that they were good | 13:46 |
| apw | ogra, right, and noone is stepping up to support those as i understand it | 13:46 |
| ogra | so we need to revert to the maverick state | 13:46 |
| apw | there is no direction that we want to support arm omap3 at all currently | 13:47 |
| ogra | i.e. to a supported set | 13:47 |
| ogra | there is | 13:47 |
| apw | ogra, from where | 13:47 |
| ogra | omap3 has the biggest community | 13:47 |
| ogra | we dont want to lose them | 13:47 |
| apw | that is desire, not direction though | 13:47 |
| ogra | its the only way to get enough developers to work with us | 13:47 |
| ogra | omap3 was never "officially supported" | 13:48 |
| apw | well that community could be served with linaro kernel then isn't it ? | 13:48 |
| ogra | so i dont get why we need to change behavior now | 13:48 |
| apw | ogra, cause we lost all of our arm engineers ? | 13:48 |
| ogra | they will use linaro hwpacks | 13:48 |
| ogra | not ubuntu images | 13:48 |
| apw | then why do we even need ubuntu images, if they are using hwpacks from linaro ? | 13:49 |
| ogra | losing omap3 would be the worst that could happen for the arm project | 13:49 |
| ogra | linaro users will use linaro hwpacks | 13:49 |
| ogra | not ubuntu images | 13:49 |
| ogra | so the one big community we can have (amd have supported up to now with "unsupported images") will be lost | 13:50 |
| ogra | we will lose all desktop and userspace testing then | 13:50 |
| ogra | not to talk about the other flavours, it took us several releases to have something for the kubuntu and xubuntu communities | 13:51 |
| ogra | so they can work on their stuff on affordable HW | 13:51 |
| apw | ogra, thats all very accurate i am sure, but the reality is we currently don't have resourece to support another kernel | 13:51 |
| ogra | 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 |
| ogra | we dont have the resources to just re-enable the maverick status in the kernel package ? | 13:52 |
| ogra | sorry but i dont get that | 13:52 |
| apw | do you know that the maverick kernel works in natty ? | 13:53 |
| ogra | i'm talking about the packaging | 13:53 |
| ogra | not the tree | 13:53 |
| apw | ogra, you mean enabling the omap build in the master branch of natty ? | 13:53 |
| ogra | what would have happened if i hadnt offered to switch to linaro kernels ? | 13:53 |
| ogra | yes, thats what i mean | 13:54 |
| apw | ogra, likely you'd have no kernels at all for omap3 ... | 13:54 |
| ogra | huh ? | 13:54 |
| apw | but ... i tried enabling omap3 at the end of last year | 13:54 |
| apw | and you tested it and rejected it | 13:54 |
| ogra | huh ? | 13:54 |
| ogra | can you please point me to any conversation about that ? | 13:54 |
| ogra | all we tested was linaro packages | 13:54 |
| apw | at end end of last year (2010) i asked you to test some kernels i made from natty master | 13:55 |
| apw | and GrueMaster reported that it was no good | 13:55 |
| ogra | sigh | 13:55 |
| apw | i can make you some more from todays tip if that helps | 13:55 |
| ogra | that might help though i dont want to waste your time, let me talk to GrueMaster first | 13:56 |
| apw | ogra, but i have no h/w to test/debug them so i am relaiant on smeone to test | 13:56 |
| ogra | indeed | 13:56 |
| apw | cirtainly if omap3 is coming for free out of master we are more able to support you in this endevour | 13:56 |
| ogra | right, i dont see any difference to maverick here | 13:57 |
| ogra | the linaro thing was an experiment to make your life easier | 13:57 |
| apw | ogra, well we dropped omap3 from master on your request | 13:58 |
| ogra | 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 |
| ogra | yes | 13:58 |
| ogra | because i didnt want to have two kernels in main | 13:59 |
| apw | ogra, and thats how we eneded up here | 13:59 |
| ogra | i know | 13:59 |
| ogra | with the thought that i wanted to put load off the kernel teams sholders | 13:59 |
| apw | sforshee, yo ... welcome | 14:10 |
| cking | ditto | 14:11 |
| tgardner | apw, echo "do_tools=false dpkg-buildpackage -aarmel -nc -uc -us"|schroot -c maverick-amd64 | 14:22 |
| === smb` is now known as smb | ||
| apw | bouncy smagoun | 14:50 |
| apw | BA | 14:50 |
| apw | bouncy smb | 14:50 |
| smagoun | was that a threat or a proposition? :) | 14:51 |
| apw | smagoun, heh, the threat was to IRC for being soooo annoying and picking the wrong nick ... :) | 14:51 |
| smb | and using anything start sm when you hit tab. :) | 14:57 |
| === diwic is now known as diwic_afk | ||
| === smoser` is now known as smoser | ||
| apw | sforshee, do you know about the team meeting today at 17:00UTC ? | 15:07 |
| apw | sforshee, its in #ubuntu-meeting in about 1:50 from now | 15:10 |
| rsalveti | apw: how are you building the omap 3 package? can you point me the config file you're using? | 15:13 |
| rsalveti | apw: then I can help trying to identify why it's not booting on my omap 3 hardware | 15:14 |
| rsalveti | since last time GrueMaster tested it basically didn't boot | 15:14 |
| apw | 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 |
| rsalveti | apw: cool, thanks | 15:14 |
| apw | rsalveti, yeah that was my memory, 'no good' but no real details as to any issues | 15:15 |
| rsalveti | yeah | 15:16 |
| ogra | theoretically the code shouldnt have changed to much | 15:16 |
| ogra | so if the config is identical to maverick it should technically work | 15:16 |
| rsalveti | not exactly | 15:16 |
| apw | ogra, indeed, though the config of the kernel overall has gone through the wringer | 15:16 |
| rsalveti | but I can also compare with linaro's config | 15:16 |
| apw | so its entirly possible things got lost, plus a bunch of omap patches dropped out as they collided | 15:17 |
| ogra | ah, so omap might inherit some x86 setting it burps on | 15:17 |
| apw | indeed so | 15:17 |
| apw | rsalveti, i'll have latest images to test and the config together and up in a few | 15:18 |
| rsalveti | apw: thanks | 15:18 |
| apw | rsalveti, does linaro have a .37 config even thought? | 15:19 |
| apw | though | 15:19 |
| rsalveti | apw: I'm just cloning their tree, but they are using .37 already, so the config should be working fine for them | 15:19 |
| apw | rsalveti, http://people.canonical.com/~apw/omap3-natty/ | 15:26 |
| apw | ogra, ok latest omap3 kernels are at the URL above ^^ | 15:26 |
| === bjf[afk] is now known as bjf | ||
| ogra | thanks | 15:27 |
| rsalveti | apw: thanks, will give it a try | 15:30 |
| === hito_jp0 is now known as hito_jp | ||
| bjf | ## | 15:31 |
| bjf | ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting | 15:31 |
| bjf | ## agenda: https://wiki.ubuntu.com/KernelTeam/Meeting | 15:31 |
| bjf | ## | 15:31 |
| tgardner | apw, have you seen bug #693042 ? | 15:41 |
| ubot2 | 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:41 |
| apw | tgardner, /me looks | 15:43 |
| apw | tgardner, thats on an old kernel, but interesting its just -server ... will ask them to test the latest | 15:44 |
| apw | tgardner, actually that appears to be init exiting | 15:46 |
| apw | so that may not be a kernel issue, we did get updates to upstart too around then | 15:46 |
| tgardner | apw, ack. ara was hassling bladernr about it | 15:47 |
| bladernr | 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:48 |
| bladernr | we're ggetting ready to start ISO testing again this week, so I'll see if there are still issues | 15:49 |
| tgardner | bladernr, cool. hassle us on IRC if the issue persists | 15:49 |
| apw | 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 |
| bladernr | I blame fader | 15:49 |
| bladernr | hrmmm... or JFo, he's too far away to do anything to me right now | 15:50 |
| bladernr | :-) | 15:50 |
| bladernr | I'll update it as soon as I know something... hopefully today or tomorrow depending on what I get roped into | 15:50 |
| apw | bladernr, yeah let us know, we are bound to forget | 15:51 |
| apw | tgardner, thanks | 15:51 |
| tgardner | apw, delegation is my specialty | 15:52 |
| apw | :) | 15:52 |
| JFo | bladernr, sorry, was looking at the other computer screen :-) | 16:07 |
| bladernr | JFo: nevermind... we got it sorted | 16:08 |
| smoser | smb, around ? | 16:08 |
| bladernr | JanC: don't need you no how ;-) | 16:08 |
| JFo | bladernr, cool | 16:08 |
| bladernr | errr... JFo not JanC | 16:08 |
| smb | smoser, yep | 16:08 |
| JFo | lol | 16:08 |
| smb | smoser, Oh, guess I forgot the server meeting | 16:08 |
| smoser | 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 |
| smoser | (i plan to leave it up for only 1 hour) | 16:09 |
| smb | 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 |
| smoser | smb, yeah, i would fill you in. | 16:12 |
| smoser | smb, would you rather i wait till after those 2 ? | 16:13 |
| smoser | i'll send you a mail | 16:13 |
| smb | smoser, That would be good. After those I should be less disctracted. | 16:14 |
| smoser | k. | 16:14 |
| smoser | 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:23 |
| smb | smoser, k, will do | 16:26 |
| === jepler- is now known as jepler | ||
| bjf | ## | 16:31 |
| bjf | ## Kernel team meeting in 30 minutes | 16:31 |
| bjf | ## | 16:31 |
| * tgardner is sure jjohansen is going to report progress on ecryptfs during the kernel team meeting in 3 minutes. | 16:58 | |
| jjohansen | tgardner: yep :) | 16:58 |
| bjf | ## | 16:59 |
| bjf | ## Meeting starting now | 16:59 |
| bjf | ## | 16:59 |
| bdmurray | It seems to me that kernel bugs regarding package installation issues, tagged apport-package, shouldn't be tagged needs-upstream-testing | 17:28 |
| tgardner | bdmurray, doesn't seem reasonable, does it? | 17:29 |
| bdmurray | tgardner: nope, not really | 17:30 |
| tgardner | is that a tag that apport applies? | 17:30 |
| tgardner | or something one of JFo's scripts did? | 17:31 |
| apw | i think it happens in the apport hooks actually | 17:31 |
| bdmurray | tgardner: which for the kernel is a part of the apport package. I could likely fix it. | 17:31 |
| tgardner | bdmurray, yeah, packaging problems definitely don't need upstream testing :) | 17:32 |
| JFo | yeah, I want to get some time at platform to look at the apport hook | 17:32 |
| JFo | there is much to be done there | 17:33 |
| bjf | apw, don't think it's apport, i think its our arsenal scripts | 17:33 |
| bjf | bdmurray, tgardner, JFo ^ | 17:33 |
| JFo | I'm sure those need adjustment as well | 17:33 |
| bdmurray | bjf: well bug 696149 has both tags and hasn't be arsenal'ed | 17:33 |
| ubot2 | 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 |
| JFo | can we look at both during the rally? | 17:33 |
| JFo | or is our time filled already? | 17:33 |
| apw | 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 |
| smb | smoser, ok so meetings are done for today. So it is the devices not showing up problem to be looked at? | 17:33 |
| apw | JFo, yes we should, we should get it on agenda | 17:34 |
| JFo | k | 17:34 |
| tgardner | apw, done | 17:34 |
| JFo | thanks tgardner | 17:35 |
| smoser | smb, yeah. let me start some instances. | 17:41 |
| bdmurray | there are some comments in bug 539467 indicating that isn't fixed | 17:42 |
| ubot2 | 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:42 |
| smb | 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 |
| apw | smb, the fix for PM was only done in lucid | 17:45 |
| apw | and the kernel was slated to be fixed in maverick | 17:45 |
| apw | but an upstream change | 17:45 |
| apw | smb, i suspect we now need a maverick nom so we can separate that from natty | 17:46 |
| smb | apw, Something on link powermanagement or that magic thing for via controllers and wd disks? | 17:46 |
| smb | hm, yes sounds like a sensible approach for maverick at least | 17:47 |
| apw | 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 |
| smb | and then "fix" pm-utils again | 17:47 |
| apw | smb, ok done | 17:48 |
| apw | smb, ok commentary added as to why i've done what i've done | 17:51 |
| apw | smb, are you looking after that one? | 17:51 |
| smb | apw, not really actively until now at least... | 17:51 |
| apw | JFo, does kernel-key work yet? will they appear on the list ? | 17:51 |
| jjohansen | apw: did you hit an issue with the AA compatibility patches not applying? | 17:52 |
| apw | jjohansen, not that i've noticed so far | 17:52 |
| jjohansen | apw: okay, if you do let me know | 17:52 |
| apw | jjohansen, i have three patches by the looks of things | 17:53 |
| * jjohansen needs to fix them for 2.6.32.2 | 17:53 | |
| apw | sorry 4 | 17:53 |
| apw | UBUNTU: SAUCE: AppArmor: Fix unpack of network tables. | 17:53 |
| jjohansen | yeah that sounds right | 17:53 |
| apw | AppArmor: compatibility patch for v5 interface | 17:53 |
| apw | AppArmor: compatibility patch for v5 network controll | 17:53 |
| apw | UBUNTU: SAUCE: AppArmor: Allow dfa backward compatibility with broken usersp | 17:53 |
| apw | jjohansen, they apply ok to 37-rc8 | 17:54 |
| jjohansen | apw: yeah interesting /me needs to look into why they are working on .37 and failing on .36.2 | 17:54 |
| smoser | smb, ok. so i'm going to launch instances | 17:57 |
| smoser | sorry for delay | 17:57 |
| smb | smoser, no worries. | 17:58 |
| apw | jjohansen, they have been rebased through each -rc so perhaps they got fixed by that as they went | 17:59 |
| jjohansen | apw: yeah that is my assumption | 17:59 |
| tgardner | apw, rebased against Linus tip and am rerunning stress on Urbana. Still up after 55 minutes. | 17:59 |
| apw | though its supprising that .2 has anything big | 17:59 |
| apw | tgardner, so thats between -rc8 and tip has helped for you ? | 18:00 |
| tgardner | apw, seems to have. absense of evidence (and all that) ... | 18:00 |
| jjohansen | apw: it doesn't, its a small fix but enough to cause the out of tree compatibility patches to fail | 18:00 |
| apw | tgardner, modulo not knowing how reproducible it is | 18:00 |
| tgardner | apw, yep. there were a couple of core mem fixes since -rc8 | 18:00 |
| tgardner | though I didn't look very close | 18:01 |
| apw | there is a 'wrong VM_BUG_ON()' which might be the trigger | 18:01 |
| tgardner | thats what I was thinking about | 18:01 |
| apw | tgardner, though that sounds like its hard to hit, but stress is stressy | 18:02 |
| tgardner | apw, I'll run it through 3 more cycles of 3600 seconds each. | 18:03 |
| apw | tgardner, thanks ... | 18:04 |
| smoser | smb, ok. 2 hosts are available at the etherpad url i gave. | 18:05 |
| smoser | root@ec2-174-129-48-53.compute-1.amazonaws.com and ubuntu@ec2-184-73-133-219.compute-1.amazonaws.com | 18:05 |
| smb | smoser, ok see it | 18:06 |
| * apw watches smoser's credit card glow warmer | 18:16 | |
| smoser | smb, ok. i'm pretty sure you're off the hook here. i'll give amazon another couple bucks to test my theory. | 18:17 |
| smb | smoser, So what would be that theory? | 18:17 |
| smb | eh | 18:18 |
| apw | smoser, we could do with an OSD for how fast money is being extracted from one ... like the brightness indicator | 18:18 |
| smb | forget | 18:18 |
| smb | just need to look at the pad | 18:18 |
| smoser | yeah. --block-device-mapping is not getting set on register. so i'll launch an instance with | 18:18 |
| smoser | --block-device-mapping sdb=ephemeral0 --block-device-mapping sdc=ephemeral1 | 18:18 |
| smoser | and see if that gets us the devices. definitely as things are right now we're not asking amazon to attach block devices, so they wont. | 18:19 |
| smb | smoser, Sounds quite reasonable. Looks like another magic part I need to know more about (instance data queries). Btw, do you know a api-tools command that would return the instance types usable for a given ami? | 18:25 |
| smoser | i dont thikn you can iterate availalbe instance type | 18:26 |
| smoser | heres the rules though: | 18:26 |
| smb | smoser, Well I mostly guessed from the description page | 18:27 |
| smoser | - instance-store can run all except t1.micro and cc1.* and cg1.* | 18:27 |
| smoser | - ebs can run all except cc1.* and cg1.* | 18:27 |
| smoser | - hvm can only run cc1.* and cg1.* | 18:27 |
| smb | Ah, had not yet seen the cc and cg types | 18:28 |
| smoser | (note, that hvm is ebs root, but is a different virtualization-type) | 18:28 |
| smoser | those are the cluster-compute instances that we just added support for | 18:28 |
| smoser | they're hvm (full virtualization) | 18:28 |
| smb | Would need to add those to some little script I started | 18:29 |
| === bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - January-18 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! | ||
| === yofel_ is now known as yofel | ||
| Sarvatt | apw: it's called byobu :) | 18:33 |
| smoser | smb, ubuntu@ec2-184-73-137-83.compute-1.amazonaws.com and you can now see the devices (that instance was launched with --block-device-mapping sdb=ephemeral0 --block-device-mapping sdc=ephemeral1 | 18:33 |
| smoser | i will change the registration of hvm instances to have that by default. | 18:33 |
| smb | smoser, Ah right. So WYRIWYG and luckily not a kernel problem | 18:34 |
| smoser | smb, http://paste.ubuntu.com/550339/ is my hacky script that sits atop other hacky scripts. | 18:34 |
| smoser | smb, right. | 18:35 |
| smoser | tomorrows build will have sane default block device mappings for hvm | 18:35 |
| smoser | http://bazaar.launchpad.net/%7Eubuntu-on-ec2/ubuntu-on-ec2/ec2-publishing-scripts/revision/263 | 18:35 |
| smb | smoser, ec2 seems to consist of too much hackyness some days... | 18:36 |
| smoser | i'm gonna kill those instances unless you want them... | 18:36 |
| smoser | oh, there is hackyness, part of my job is to make people not need to know the hackyness | 18:36 |
| smoser | "just works" | 18:37 |
| smoser | sorry for wasting your time. | 18:37 |
| smb | smoser, not needing them further. been off. no problem. maybe some time of next week we might spend on relaying which part of hack is needed where and where to find it | 18:38 |
| smb | what I would like to have would be some simple way to define a set of types to start up for coverage tests | 18:39 |
| smoser | well the hack we need on hvm instances is due to bug 684875 | 18:39 |
| ubot2 | Launchpad bug 684875 in linux (Ubuntu Natty) (and 3 other projects) "Patch to Natty 2.6.37-virtual breaks non-EC2 users (affects: 1) (heat: 126)" [High,Confirmed] https://launchpad.net/bugs/684875 | 18:39 |
| smb | yeah, I should take time tomorrow to actually prepare that revert for natty to go in | 18:40 |
| smb | apw, When are you planning to do that final upload? | 18:40 |
| smb | at least before ralley | 18:41 |
| apw | smb, i am intending to upload late tommorrow or early thursday morning | 18:41 |
| apw | depending on what linus does, so yes, that its through the AAs before i get on the plane | 18:41 |
| smb | That sounds like enough time. | 18:41 |
| cluk | Hi, I am running Lucid on a Dell E6410 and am affected by the 'blank screen on boot' bug #561802. | 18:51 |
| ubot2 | Launchpad bug 561802 in linux (Ubuntu Lucid) (and 2 other projects) "[i915] blank screen on Latitude E6410 (NOT E6510) (affects: 63) (heat: 337)" [Medium,In progress] https://launchpad.net/bugs/561802 | 18:51 |
| cluk | I would really like to help fixing this issue but I would need some developer support. :) Could one of you tell me where to ask for help? | 18:53 |
| apw | cluk, what graphics h/w does this machine have? | 19:00 |
| cluk | 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) | 19:00 |
| cluk | I am getting the blank screen with all the latest lucid, lts-backport-maverick and lts-backport-natty kernels. | 19:01 |
| cluk | Even drm-intel-next as of yesterday is the same. | 19:02 |
| cluk | I tried bisecting on drm-intel-next as I have one older kernel build from that repo which does not show this behaviour. | 19:04 |
| jjohansen | cluk: commit b599c0bca1e08a89a7fc4305bc84f4be30ada368 is the bad one for me | 19:07 |
| jjohansen | cluk: I haven't chased my blank screen issue beyond that yet | 19:08 |
| * manjo getting lunch will be back soon | 19:11 | |
| cluk | jjohansen: I found c48c43e422c1404fd72c57d1d21a6f6d01e18900 to be good, while b4ce0f85159f77f208a62930f67b4e548576a5a3 was bad. | 19:12 |
| cluk | but reverting that commit on drm-intel-next head still booted to a blank screen. | 19:13 |
| cluk | From all I read and tried I would guess that this is a kind of race or timing problem. | 19:14 |
| cluk | Even those kernels that 'work' sometimes wakeup from suspend with a blank screen. | 19:15 |
| jjohansen | cluk: possibly, like I said I didn't chase it any farther on the machine I have experiencing problems yet | 19:18 |
| bjf | @now | 19:32 |
| cluk | jjohansen: anything I can do to help fixing this? I could spend some time on this issue this week. :) | 19:37 |
| jjohansen | cluk: hrmmm, I haven't thought to much about it yet. My initial reaction was find the bad commits, but it seems to be more than that | 19:39 |
| jjohansen | cluk: chasing down the race would be great, but it seems a bit much to ask | 19:41 |
| cluk | jjohansen: aehm. I could try if anyone could give me some hints, perhaps. :) | 19:46 |
| jjohansen | cluk: hehe, well that is the problem I am not sure where to start on the race | 19:47 |
| jjohansen | cluk: actually my first pass would be to see just how repeatable the problem is, does it fail 50% of the time, on boot etc. What of suspend, maybe its 100% there | 19:48 |
| jjohansen | This could give some different paths to look at, or maybe its just multiple problems | 19:49 |
| jjohansen | cluk: chasing from there gets a little more ugly, I would probably start looking at the code and poking in a few debug statement/counters | 19:50 |
| jjohansen | but then /me isn't very familiar with the drm stack so /me isn't sure of the best way to approach it | 19:51 |
| cluk | jjohansen: I never got a working screen with a normally non-working kernel and vice versa here. | 19:51 |
| jjohansen | cluk: hrmm, can you go back further and get a working screen? | 19:52 |
| cluk | jjohansen: what does further mean here? :) I got a working kernel from c48c43e422c1404fd72c57d1d21a6f6d01e18900 almost all others are failing. Only older 2.6.32 versions are working too. | 19:54 |
| jjohansen | cluk: so c48c43e422c1404fd72c57d1d21a6f6d01e18900 gives you a working screen? | 19:55 |
| cluk | I can tell you the bad commit for those too, if you like. | 19:55 |
| cluk | jjohansen: yes. | 19:55 |
| jjohansen | and if you step forward 1 it breaks | 19:55 |
| jjohansen | ie b4ce0f85159f77f208a62930f67b4e548576a5a3 | 19:56 |
| cluk | no, not exactly. It breaks with: b4ce0f85159f77f208a62930f67b4e548576a5a3 | 19:57 |
| cluk | and I can go 1 rev back and there it works too. | 19:57 |
| jjohansen | ah okay, sorry I don't have intel-drm-next infront of me | 19:57 |
| cluk | But reverting b4ce0f85159f77f208a62930f67b4e548576a5a3 on head does not fix it. :( | 19:58 |
| jjohansen | cluk: right but other later commits my also be causing problems | 19:59 |
| cluk | he he. yes. | 19:59 |
| jjohansen | cluk: have you tried head, with all changes to intel drm reverted? | 20:00 |
| cluk | jjohansen: do you mean: head of Linus' repo with all drm intel changes up to the working one reverted? | 20:03 |
| jjohansen | cluk: yep | 20:04 |
| jjohansen | trying to isolate intel drm changes from changes to the rest of the kernel | 20:04 |
| jjohansen | perhaps there is something else in the rest of the kernel causing issues | 20:04 |
| cluk | jjohansen, no, did not try that. | 20:05 |
| jjohansen | its worth a try | 20:05 |
| cluk | ah ok. Reverting all drm intel related changes means 'reverting the merge commits from drm-intel-next / drm-intel-fixes'? Or is there an easier way? | 20:07 |
| === sforshee_ is now known as sforshee | ||
| jjohansen | cluk: in this case I think the revet of the merge should do it | 20:14 |
| * jjohansen lunches | 20:16 | |
| hallyn | apw: (notice you listed in udev contributors :) do you know why our udev package doesn't do scsi_wait_scan at startup, while debian's does? | 22:16 |
| apw | hallyn, likely cause we don't want to wait for all the disks? | 22:17 |
| apw | we only care to wait till the one which represents / arrives, the rest can arrive as an when they fancy | 22:17 |
| hallyn | hm, unfortunately that's not always true :) | 22:22 |
| hallyn | now, the only case I know of where it's not (so far) involves multipath, and that's what I'm trying to figure out - | 22:22 |
| hallyn | should I just do scsi-wait_scan in the initramfs script shipped with multipath, or should we do it in udev | 22:23 |
| apw | hallyn, i suspect that use case is not 'supported' | 22:23 |
| apw | i think we should poke scott | 22:23 |
| apw | and see what he thinks | 22:23 |
| hallyn | which scott? | 22:23 |
| hallyn | apw: do you mean multipath not supported? | 22:26 |
| apw | hallyn, keybuk | 22:29 |
| apw | hallyn, as in never thought about and therefore not supported in the current design | 22:30 |
| apw | probabally as an interim doing a wait in initramfs will likely do the trick | 22:30 |
| apw | its not sure how one can know how many paths to wait for, i guess it depends if new paths can be added as the paths come up | 22:30 |
| apw | if so, then there should be no need | 22:31 |
| hallyn | apw: ok, thanks. | 22:32 |
| cluk | jjohansen, I talked to the guys at #intel-gfx about the blank screen issue and jbarnes pointed me to the patch in | 22:39 |
| cluk | http://lists.freedesktop.org/archives/intel-gfx/2011-January/009112.html | 22:39 |
| cluk | which fixed the issue. | 22:39 |
| cluk | I tested this patch on top of drm-intel-next head and on top of the bad commit mentioned earlier. | 22:40 |
| cluk | Both cases seem to work correct with this patch. | 22:40 |
| jjohansen | cluk: interesting I'll have to give that a try | 22:46 |
| jjohansen | cluk: thanks | 22:46 |
| cluk | jjohansen, the patch has just been committed to the drm-intel-fixes branch. as 369581028e2528122cc109abacf11766ae231f01 | 22:55 |
| === sconklin is now known as sconklin-afk | ||
| === JanC_ is now known as JanC | ||
| yigal | I patched the Maverick kernel which alters a few files in drivers/input/mouse it went well and now I'm able to the touchscreen on my device, Viliv S5. Now I want to alter a few files in drivers/input/net/wireless to get the wireless up and running but I would prefer to not have compile the kernel all over again, is there a way to use the original src and recompile the kernel faster than before? I'm using a z530 and it takes | 23:12 |
| yigal | s/./? | 23:13 |
| jjohansen | yigal: you can do partial compiles | 23:13 |
| yigal | I thought this would be possible, I'm just not sure how | 23:13 |
| jjohansen | yigal: I assume your using the ubuntu build system? doing fakeroot debian/rules ? | 23:14 |
| yigal | not exactly old Debian way make-kpkg | 23:14 |
| jjohansen | hrmm, I've actually never used that | 23:15 |
| yigal | but it uses debian/rules and I used fakeroot | 23:15 |
| jjohansen | right | 23:15 |
| yigal | just not from git | 23:15 |
| jjohansen | look in debian/stamps/ | 23:15 |
| yigal | ok | 23:15 |
| jjohansen | there should be some build stamp files | 23:15 |
| yigal | yes | 23:15 |
| jjohansen | if you remove the build stamp files, it will run through the build again, but make will detect the .o files | 23:16 |
| yigal | ok | 23:16 |
| yigal | great | 23:16 |
| yigal | so I can make $xconfig etc., and then go through what I normally what I would have done? | 23:16 |
| yigal | oldconfig,menuconfig etc. | 23:17 |
| jjohansen | you should be able to | 23:17 |
| jjohansen | the important part is to not clean out the .o files | 23:18 |
| yigal | jjohansen: if i'm patching a certain driver should I delete that driver | 23:18 |
| yigal | from the original build | 23:18 |
| jjohansen | yigal: it doesn't hurt to delete its .o files, but it really shouldn't be necessary | 23:18 |
| jjohansen | make should detect the .c files have been updated and recompile those | 23:19 |
| yigal | very smart | 23:19 |
| yigal | good to know | 23:19 |
| yigal | I don't expect it to work smoothly but if it does, that would be great! | 23:19 |
| yigal | thank you | 23:19 |
| jjohansen | well there are times that it doesn't work because the make file is missing some dependency but it usually works | 23:20 |
| === bjf is now known as bjf[afk] | ||
| cluk | Ok, thanks for your help and bye for now! | 23:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
