=== smb` is now known as smb === henrix_ is now known as henrix === Kiall is now known as zz_Kiall === zz_Kiall is now known as Kiall [09:28] henrix, when we did natty did we also do natty/ti-omap4 ? [09:29] apw: i'm not sure about that. let me check... [09:54] Hi everyone, i'm working on an ubuntu-server image on my Pandaboard - :) - and i'm trying to connect a GPS / RFID / GPRS to my system; the problem is that in a normal ubuntu environment theses devices are attached on /dev/ttyUSB* ( for GPS and GPRS) and /dev/ttyACM* ( for RFID) but on my system they are plugged on /dev/usbdev*.** [09:54] i found some tutos that show how to enable usbserial for devices using their idProduct / Vendor : but i need this to be natively done by the system , regardless the GPS i'm connecting [10:03] i've also to mention that for RFID i see in dmesg output : ttyACM0 : USB ACM device but when i check /dev , no ACM entries are there except the newly created usbdev2.1 and for GPS also dmesg tells FTDI USBSerial Device converter now attached to ttyUSB0 but also i can't fin d this entry in /dev but i see that usbdev has been created! [10:05] i've also to mention that for RFID i see in dmesg output : ttyACM0 : USB ACM device but when i check /dev , no ACM entries are there except the newly created usbdev2.1 and for GPS also dmesg tells FTDI USBSerial Device converter now attached to ttyUSB0 but also i can't fin d this entry in /dev but i see that usbdev has been created! [10:25] henrix, ok i have pushed the missing CVE commits to ti-omap4 so when you make it it should be complete. commentary to kernel-team@ for the record. [10:26] apw: ok, thanks. i'll need to sync with herton, as he's doing all the omap4 kernels (with ppisatti) [10:27] thierry, might be a configuration option missing or something, do you have a bug filed? [10:27] FTDI also often misses vendor/product IDs [10:28] ogra_, FTDI ? [10:28] * ogra_ had some devices that needed a manual fix to then show up properly in the next kernel iteration) [10:28] apw, serial driver [10:28] ogra_, well the implication of the above is that the device works in an x86 kernel at the same level [10:30] apw, right, that would apply if he used the same kernel versions on both arches ;) [10:31] ogra_, indeed, and hopfully the bug has that info ... [10:31] ogra_, as i think other than natty things are rebase so should be in sync, if its natty they just missed the boat [10:34] apw: configuration files i've missed or that aer missing in ubuntu-server? [10:35] thierry, no, we were talkin abot kernel build configuration [10:40] thierry, indeed what ogra_ said [11:20] http://askubuntu.com/questions/176970/how-can-i-remove-a-mainline-kernel-and-move-back-to-a-supported-kernel/176977#176977 How is a "mainline kernel" defined? How is a "stock Ubuntu kernel" defined? What is the difference? [11:22] ogra_: apw : exactly, i had this problem once before, but it was me building the kernel with options with PTXdist ( hey LetoThe2nd :) ) ... but there is no way to encoutner this problem???? [11:23] bullgard6, a mainline kernel is a kernel built from virgin upstream sources, typically though not exclusivly found in the mainline kernel archive (https://wiki.ubuntu.com/Kernel/MainlineBuilds). A stock ubuntu kernel is one built from our modified sources and delivered via the main archive. [11:24] thierry, i don't get you, "no way to encounter this problem?" [11:25] apw: Thank you for your help. [11:25] as i've understood, the usbserial driver is not built in , it's included as a module i guess, i have to activate for each device i need, there is no way to rebuild it ? [11:26] thierry, i don't think we have said as much as that. we have suggested that perhaps the kernle you have does not have the same options as the working on you mentioned, here i am assuming arm against x86 kernels are different [11:26] thierry, without a real idea of the issue i have no idea what if anything can be done about it [11:27] thierry, if activating the serial driver by hand works for you, ie modprobe something makes it work you could probabally just add that module to /etc/modules as a work around [11:28] otherwise, some information on what version of the kernel is broken on what platform and what version is working on what platform, would help [11:34] apw: i'm using the 3.4.0-1485-opa4 kernel, an ubuntu-server image ( hey ogra_ ) , on a Pandaboard B1 [11:36] omap* and not opa [11:37] thierry, and which one do you find them automatically detected correctly [11:38] for USB-serial devices , no one i have ( i tested an RFID, a GPS and GPRS) [11:38] apw: for USB-serial devices , no one i have ( i tested an RFID, a GPS and GPRS) [11:41] apw: the sudo echo usbserial >> /etc/modules works [11:42] should i launch a bug or something like this? [11:42] thierry, that information should be in a bug indeed. include the lsusb output for the devices which don't work [11:43] ok , but in which bugtracker? [12:01] * henrix -> lunch === henrix is now known as henrix_ === henrix_ is now known as henrix === davmor2_ is now known as davmor2 === rtg is now known as rtg-afk [14:41] * ogasawara back in 20 [15:46] ogasawara: mumble? [15:46] bjf: sure, just a sec [15:53] * ogra_ is really happy to see that rtg raised the ulöimit for omap4 kernels too, finally we can run our wine apps properly on the panda :P [15:54] ogra_, it'll take a bit for that change to propagate.... [15:55] ogra_, though I'm curious which release you are concerned about ? herton pointed out the Lucid ti-omap is no longer maintained. [15:55] rtg, well, there is no wine on arm ... (there is but there are no executables to run) [15:55] rtg, that was pure sarcasm [15:56] ogra_, oh, I didn't get it :) [16:40] ** [16:40] ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting [16:40] ** [16:56] cking: so I have requests to reenable IMA, the problems that caused it to get blacklisted are supposed to be fixed. I asked the maintainer if she had anyway to measure and she said no, so I am looking for ideas on what tests to run etc to verify that we can reenable IMA. [16:56] Basically I'd like to pick your brain when you have some time in the next few days [16:57] jjohansen, which IMA are you referring to? [16:58] cking: CONFIG_IMA its a security module todo with with measuring system integrity. [16:58] It got blacklisted in our config due to a bug that caused it to chew up a lot of resources [16:59] err bug may not be the right word, they actually kind of designed it to do that without realizing their design choice was bad [17:00] jjohansen, OK, I've got zero knowledge on this, but I can ramp up tomorrow morning on it. [17:01] cking: yeah I am just a little ahead of you and just looking for ideas, its not a big rush [17:02] jjohansen, OK - well let me get upto speed and then we can kick some ideas around. [17:04] jjohansen, is there a bug you can refer me to on this? [17:05] sconklin, is there any chance that you can send me some info concerning how to graph the autotest data using jenkins? [17:05] cking: well, it's not working at the moment, but I can send you a description of what we have in the tools repo [17:06] sconklin, ah, not working as in temporarily busted but will be fixed? [17:06] undergoing a rewrite [17:06] because it never really worked well [17:07] ah [17:08] look in the kernel-testing repo in the benchmarking subtree [17:08] there's a script named make-all-charts which is run from a cron job on our jenkins server. Ignore the rsync parts. [17:09] but I'll warn you, it's really ugly and doesn't scale, which is what I'm addressing in the rewrite right now [17:10] sconklin, ok, so if I back off on my implementation will can I come back to in a week or so and plug it in to the new graphing infrastructure? [17:10] bah, that made no sense [17:11] sconklin, just in case you wonder where the 12 or so CVEs went over night, i have updated the quantal armadaxp to match reality [17:11] apw, I did wonder, but not too much [17:11] cking: yes [17:11] sconklin, OK - well, I'm almost done on my bit, I will put it into holding position [17:11] cking: and you can help me test the new structure. There's really no sense in you looking at the older [17:12] sconklin, I'm very happy to throw new stuff in to exercise it :-) [17:12] cking: start collecting your data files, and you can graph them later. Just pull the latest kernel-testing master-next, as I added some new metadata to help make it easier to filter the data files [17:13] cking: I haven't been able to find a bug for it, it was first noticed on kernel.org to be a problem and apw added a wi to add the blacklisting to the enforcer [17:13] The rewrite of this is partially because I started thinking about what it would be like for someone else to use it, and realized that it was very bad [17:14] jjohansen, cking yeah it added something big somewhere important and some other locking which sucked and made it really slow [17:14] sconklin, ok, fair point. In that case, can you zip me an email on how I should be collecting the data (and where it ends up so I can sanity check my tests) and then I'm happy to run some tests to collect data over the next week or so. [17:15] jjohansen, ack [17:15] cking: let me dig up some more details and I will forward them to you [17:16] jjohansen, much appreciated, thanks! [17:16] cking: ack, I'll have that to you by EOD for me [17:17] sconklin, ta === rtg-afk is now known as rtg === jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues September 11th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! [17:28] bjf, what did you ultimately find was the solution for the BIOS dev name issue ? [17:30] rtg, cjwatson submitted a fix to resolve it. i had to add the "biosdevname" package to my pkgsel list in my preseed as a work-around [17:30] rtg, are you seeing issues? [17:31] bjf, nah, just curious. what was the bug number for that ? [17:31] bug 1043936 [17:31] Launchpad bug 1043936 in biosdevname "Biosdevname not installed in the target after server install" [Critical,Fix released] https://launchpad.net/bugs/1043936 [17:55] * rtg -> lunch === doctormot is now known as doctormon [18:09] * henrix -> EOD === yofel_ is now known as yofel [19:09] jjohansen: afair, after turning on ima, if you add lots of files to a file system, you shouldn't see kernel heap space used. (that was the old bug) [19:10] kees: right, need to valid that but also no regression in other cases if we are going to SRU to precise [19:11] kees: basically I just need to hammer out a test plan with a bunch of tests, and get it going [19:12] kees: well that and get a ppa up for people who want IMA on precise for the interim [19:14] oh hrmm, ogasawara being past FF we would need to file an exception to turn on a CONFIG right? [19:14] jjohansen: not necessarily for the kernel, we don't have our kernel freeze until oct 4 [19:15] jjohansen: just shoot an email to the mailing list if you need us to twiddle a config option [19:15] ogasawara: okay, so we are looking at enabling CONFIG_IMA, its currently black listed. we will want to get some get supporting tests that it isn't still causing problems before turning it on [19:16] ogasawara: so I am going to work at making sure its all good before firing of that mail [19:16] jjohansen: ack === bjf is now known as bjf[afk] === chrisccoulson_ is now known as chrisccoulson [19:35] * smb -> gone === henrix is now known as henrix_ === bjf[afk] is now known as bjf [20:25] jsalisbury, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1045027/comments/8 [20:25] Ubuntu bug 1045027 in linux "iPXE kills kvm with KVM: entry failed, hardware error 0x80000021" [Critical,Triaged] [20:43] rtg, i also encounter bug 1046029 sometimes [20:43] Launchpad bug 1046029 in debian-installer "Network device not configured correctly" [Undecided,New] https://launchpad.net/bugs/1046029 [21:12] rtg, thanks. That saved allot of testing requests :-) [21:17] bjf, thats gotta raise hell with your Jenkins jobs that re-provision all the time [21:17] rtg_: it can be problematic, though i'm only seeing it on one of the three systems [22:14] * rtg -> EOD [22:35] jjohansen: is there such a thing as a apparmor "test suite"? [22:36] bjf: yes [22:36] jjohansen: does QA run them? [22:36] bjf: its been integrated into qrt [22:36] jjohansen: ah, and do you know if they run that part of qrt? [22:37] jjohansen: are they part of any of the "kernel" qrt tests? [22:37] bjf: I don't know, the apparmor tests are also split, so there are userspace tests and kernel regression tests [22:38] bjf: give me a bit to find which parts of qrt trigger the kernel apparmor bits [22:38] the are not part of the test-kernel* scripts [22:38] jjohansen: i'd very much like to start running them as part of the kernel testing [22:38] jjohansen: test-apparmor.py [22:38] jdstrand: thanks [22:38] jdstrand: are they all there? [22:39] jdstrand: in the one place i meant [22:39] bjf: test-apparmor.py has all the different apparmor testsuites, yes. it [22:39] skips one I think by default [22:39] * jdstrand looks [22:39] jdstrand: thanks, will take a look at it [22:40] it skips the stress tests [22:40] bjf: note test-apparmor.py is just a wrapper around the old crufty Make, and shell test scripts, there are plans to update this but it hasn't happened yet [22:41] jjohansen: ack, like the other qrt tests. i'm used to that. [22:41] but there is a command line argument to enable them [22:41] bjf: and you don't want the stress tests atm [22:41] bjf: well at least if you want your tests to complete [22:42] jjohansen: I think one of them completes after a long while... the parser? I forget [22:42] anyhoo, yeah, they are in there [22:44] jdstrand: well, the kernel one at one point wouldn't and some of the parser ones wouldn't either. And I have some parser ones that will take down tangerine [23:15] RAOF: do you have the SRU desk today? [23:15] bjf: I do, yes. [23:16] RAOF: sweet! i have some kernel packages ready to go to -updates :-) [23:16] Shoot. [23:18] RAOF: bug 1036553 [23:18] Launchpad bug 1036553 in linux "linux: 2.6.32-42.96 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1036553 [23:18] RAOF: bug 1036178 [23:18] Launchpad bug 1036178 in linux "linux: 3.0.0-25.41 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1036178 [23:18] RAOF: bug 1041217 [23:18] Launchpad bug 1041217 in linux "linux: 3.2.0-30.48 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1041217 [23:19] RAOF: bug 1041406 [23:19] Launchpad bug 1041406 in linux-armadaxp "linux-armadaxp: 3.2.0-1607.11 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1041406 [23:19] RAOF: that's all for now :-) [23:19] Wow. All the kernels! [23:33] bjf: They require the various linux-*-metas as well, don't they. [23:33] RAOF: yup [23:33] RAOF: those should all be there, ready as well [23:33] They are; the bugs are in a slightly different form to when I last did the kernel release, though. [23:34] They've got the -meta and -lbm task set to Invalid, which threw me a bit. [23:34] looking [23:35] RAOF: that is supposed to mean they were not an abi bump so didn't require new -meta or -lbm packages [23:35] Yeah; but at least 1041217 *does* bump abi. [23:35] looking [23:36] hmmm [23:37] RAOF: this may be a respin so the meta tasks were set in a different bug [23:38] bug 1036581 [23:38] Launchpad bug 1036581 in linux "linux: 3.2.0-30.47 -proposed tracker (dup-of: 1041217)" [Medium,In progress] https://launchpad.net/bugs/1036581 [23:38] Launchpad bug 1041217 in linux "linux: 3.2.0-30.48 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1041217 [23:39] Aah, yeah. infinity left himself a note on the bug about that. [23:39] RAOF: ^