=== steve__ is now known as sbeattie === gfrog_ is now known as gfrog === AceLan_ is now known as AceLan [11:03] hallyn_, heh you should indeed === fmasi_afk is now known as fmasi [13:05] hi, I'm trying to read i2c data and from userspace the example code uses ioctl [13:06] I want to read i2c data from a kernel module and would like to figure out how to read from the device [13:06] can I just use the normal open read write close functions? [13:12] alex116, how about https://www.kernel.org/doc/Documentation/i2c/dev-interface === kentb is now known as kentb-afk === fmasi is now known as fmasi_afk [13:35] maybe https://www.kernel.org/doc/Documentation/i2c/writing-clients === fmasi_afk is now known as fmasi [14:10] I was hoping I could just use the loaded driver's functions because thats all ioctl does [14:41] Can I somehow make it impossible (or near impossible) for apt to even consider removing linux-image-server, linux-server, linux-headers-server, etc..? [14:44] zequence: It's SRU time again, if you missed out on the new bugs. [14:44] igalic: There's no reason it would remove them unless you ask it to remove something they depend on. [14:44] igalic: As a general rule, people are expected to read apt's output when it tells them what it intends to do. [14:45] infinity, arn't they even manually installed top levels so it should be hard to force them off [14:46] igalic, how did you get into a sitruation where it wanted to, what did you ask for [14:46] that it though could only be solved by so removing it [14:47] apw: They're manually installed, yeah. Not that autoremove would ever pull them anyway, since they're never installed as deps. [14:47] apw: So, people removing them are doing it intentionally (ie: by removing the kernel they depend on) [14:47] i can only assume you asked it to remove the latest kernel ? [14:47] We're trying to remove automatically installed kernels. We don't quite trust autoremove, since it tends to uninstall things that are "running". This "recipie" http://dpaste.com/1464493/ (from https://help.ubuntu.com/community/Lubuntu/Documentation/RemoveOldKernels ) however will remove /other/ stuff that we'd rather kept. [14:48] (I like how the automatic section is actually empty) [14:51] oh.. that's the latest kernel. That's why it's removing it. [14:52] so that "documentation" is lying. [14:53] ogasawara, I understand you will discuss this next week, but do you today have a feeling for whether you'll end up with 3.13 or 3.14 for the LTS? [14:54] diwic: most likely 3.13 [14:54] ogasawara, thanks, that was my guess too [14:56] apw, dropped 'UBUNTU: SAUCE: (no-up) drm -- stop early access to drm devices' during the rebase. Do you think we still need it ? === fmasi is now known as fmasi_afk [15:01] igalic: "apt-get autoremove" will not remove the running kernel. Random other weird snippets on wikis are generally suspect. [15:02] infinity: apt-get autoremove will not remove the running kernel, but it will remove the running kernel's utils, tools and headers. [15:02] igalic: Not anymore. [15:02] rtg, i think i am supprised to still find it applied, i thought that that was fixed another way in upstream now [15:03] apw, well, I've been faithfully forward porting it for several releases [15:03] igalic: That was fixed in saucy. In precise, it'll yank tools probably, yeah. Maybe also headers. [15:03] rtg, hehe ... oh well ... [15:03] infinity, didn't we fix those deps back in the end? i thought we did [15:03] apw, guess we'll find out. I haven't even boot tested this pile yet [15:04] infinity: that's badd, because we're running LTS [15:04] apw: I may have made the header fix in precise. Can't fix the tools issue without backporting the rename/reorg. [15:04] infinity: can you link me to the bug? === kentb-afk is now known as kentb [15:04] infinity, point, that we have done for the lts-backport kernels, saucy onwards but .. yes not before that [15:05] igalic: Okay, just verified, precise won't autoremove headers, but it will autoremove tools. === fmasi_afk is now known as fmasi [15:05] igalic: And the tools problem is hard to solve without us reorganizing the precise kernel packages. [15:05] (Which is probably not worth doing with another LTS around the corner, IMO) [15:05] Given that the number of people who need tools installed is tiny. [15:06] perf top is invaluable. [15:06] For normal users? [15:07] >_o [15:07] You and I may define normal differently. :P [15:07] Define normal users. [15:07] s/normal/average/ [15:07] Statistically, very few people use perf. [15:07] I'm a Unix Admin. I don't know what you mean. [15:07] And the people who do use it probably intersects well with people who can read the output of "apt-get autoremove" and say "no" when it's not what they want. [15:08] Yes, except we have everything puppetized on hundreds of machines. [15:08] Anyhow, we *could* backport the whole tool renaming madness to precise, I'm just not sure it's worth the pain. [15:09] infinity: if I run the cool new kernels on LTS, will that still be an issue? [15:10] apw: Is the tool renaming magic represented in linux-lts-saucy? [15:10] i.e.: linux-image-generic-lts-saucy [15:10] * infinity looks. [15:10] (or any other) [15:10] infinity, yes [15:10] Yeah, looks like that works. [15:11] infinity, oh well ... perhaps the answer is "in the new one" [15:11] igalic: Only lts-saucy, not the earlier ones. [15:11] But, I'd need to backport the matching apt fix for that. [15:11] it may not have hit updates yet, or is about to now or something [15:11] infinity: apw: can you link me to the issues describing this? [15:11] linux-tools-3.11.0-12-generic linux-tools-3.11.0-13-generic linux-tools-3.11.0-14-generic are all what I'd expect in precise. [15:12] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1205284 [15:12] Launchpad bug 1205284 in linux (Ubuntu Precise) "linux-tools naming is not scalable to multiple source packages" [Medium,Fix committed] [15:12] infinity, the bits for master might not be in yet, and there is a common tools package fix pending on the lts-saucy branch [15:13] infinity, yeah the wrapper fixes are pending for the next sru round for master [15:13] apw: s/next/current/, or in another month? [15:13] as in only on master-next right now [15:14] Bummer. Well, I'll backport the apt fix, since that's trivial. [15:14] ie the /usr/bin/perf won't recognise the new perf binaries till that fgoes out [15:14] yeah, it got missed in testing [15:14] its not like you cannot find them manually so not world ending, they are there installed [15:18] apw: Alright, apt backport uploaded. [15:18] wowzers! [15:19] apw: If someone wants to mangle all the tools crap in 3.2, that might make somoene happy, but I personally think it's likely not worth the effort. [15:19] infinity: do you have a bug for that also I can track? [15:19] igalic: Same bug I pasted above. [15:23] so, once this gets promoted (demoted?) to precise, if we have linux-image-generic-lts-saucy installed, and the system's apt-to-date, we can simply have Unattended-Upgrade::Remove-Unused-Dependencies "true"; and everything will be perfectly fine. [15:25] bjf: i'm preparing the P/omap4 kernel [15:25] ppisati, ack [15:28] * ppisati disappears for a bit [15:30] igalic: If you want headers too, that would be linux-generic-lts-saucy [15:30] igalic: And linux-tools-generic-lts-saucy for tools. [15:30] infinity: linux-generic-lts-saucy installs headers also? [15:31] igalic: "linux-generic" depends on "linux-image-generic" and "linux-headers-generic" (trade "generic" for flavour du jour, like generic-lts-saucy) [15:31] infinity: I think I've asked this question a couple of times, but, what's the difference between -generic, -server, -chewgum, -etc ? [15:32] igalic: These days, generic is the only flavour, though there's a fake not-quite-flavour called virtual, which is actually just generic without most of the modules. [15:33] igalic: But, on LTSes, you'll have different generic options for the HWE backport kernels (like lts-raring, lts-saucy, etc). [15:33] Oh, I guess it's not fair to say "generic" is the only one, as there's also lowlatency. [15:33] But it's the only one built from the master sources. :P [15:34] What's that mean? [15:35] There's a "linux" source package, maintained by the Canonical kernel team, and it only produces the generic (and virtual) flavour. [15:35] (and notionally the server flavour) [15:35] lowlatency is a rebased fork maintained by the Ubuntustudio team, which has a few different twiddles. Not particularly ideal for servers, so probably of little intrerest to you. [15:35] apw: There is no server flavour. [15:36] (Not anymore) [15:36] there is a linux-server and linux-{image,headers}-server though [15:36] which are used in server images, which is why it is notional [15:37] apw: Sure, but it just installs generic. ;) [15:37] right, just .. dunoo ... being a pedant [15:37] I suppose it keeps the option open if we feel the need to fork configs again some day. [15:37] But with scheduler improvements and the like, forked configs are less interesting over time. [15:37] It would be nice to install -server and have sysctl settings actually worthy of a server. [15:38] igalic, that would be possible, as it has its own meta package [15:38] igalic, if there was a definative set which made sense [15:43] apw: disabling the oom killer for instance ;) [15:45] igalic, i don't think disabling that is going to solve any issues, yo should never ben runnig a server to the point it would need to [15:49] Disabling the OOM killer doesn't magically prevent you from running out of RAM. [15:50] It does, on the other hand, assume that the first few processes started are the only ones allowed to have memory leaks, which might be a desired behaviour for some. [15:50] No, it doesn't but it magically prevents the kernel from not killing processes even though I'm NOT out of RAM. [15:51] igalic: When you're out of RAM, all your processes are out of RAM. Until a sufficiently large one crashes. *shrug* [15:51] The OOM killer attempts to make intelligent decisions based on usage patterns. It's not necessarily any dumber than the non-oom-kill algorithm of "let stuff crash when it tries to malloc()". [15:52] igalic: Without the OOM killer, you could leak with some Java servlet, but the malloc() that hits the brick wall could be init. Instant kernel panic, game over. [15:53] igalic: You can't control WHICH process hits the last available page and dies. [15:53] please read http://www.twistedmatrix.com/users/glyph/rant/softethics.html [15:54] your point with that ? [15:54] or is that a total no-sequiter [15:54] apw: It's unethical to prevent init(8) from dying, if that's what it chose to do. [15:55] apw: How dare we stand in the way of its suicide attempt via malloc(). [15:55] igalic, anyhow if you can change it via sysclt, one can do that, so ... [15:57] apw: read the bit about car manufacturers. [15:59] (I think a good resource is also http://www.loper-os.org/?p=284 ) [15:59] igalic: It's a poor analogy, in reference to the above discussion. If your car runs out of gas, do you think it would be appropriate for it to jam a piston through the hood and send a tire flying off the side of the road? [16:00] igalic: Sure, if you had just kept the tank topped up, you'd be a responsible driver, and you'd still have an engine. On the other hand, lolwut? [16:01] I think a better "fuel" analogy is this one https://lwn.net/Articles/104179/ ;) [16:03] so all one needs to do is swtich to full commit mode for allocation and ensure you have enough swap [16:04] And suddenly you have a predictable VM. YAY. It's almost like I'm using a Unix. [16:06] yeha right, like they wern't the same === fmasi is now known as fmasi_afk === fmasi_afk is now known as fmasi [17:09] rtg: i'm building a test kernel [17:10] ppisati, ack, I'm about to email a comment to robher about the mac learning patch [17:12] Hi guys. I'm back to working on embedded projects and I'm rusty on kernel building. What is a good resource for building a kernel from source on Ubuntu/Mint? The Wiki appears to be a bit dated. Thanks [17:16] [flag@luxor ubuntu-saucy]$ git fetch origin [17:16] [flag@luxor ubuntu-saucy]$ git rhard origin/master-next [17:16] HEAD is now at a223125 UBUNTU: SAUCE: (no-up) apparmor: Fix tasks not subject to, reloaded policy [17:16] [flag@luxor ubuntu-saucy]$ git cherry-pick -sx f0915781bd5edf78b1154e61efe962dc15872d09 [17:16] [master-next 15fa8df] ARM: tlb: don't perform inner-shareable invalidation for local TLB ops Author: Will Deacon 3 files changed, 123 insertions(+), 30 deletions(-) [17:16] rtg: ^ [17:16] rhard is an alias for 'reset --hard' [17:17] ppisati, huh, well maybe I fat fingered something. [17:17] rtg: actually that hash comes from rmk's git tree [17:18] ppisati, well, try the same patch from Linus' tree [17:18] rtg: but if you don't have that remote, it would probably say 'unknown hash or something' [17:18] rtg: let's see [17:21] disregard. I had to add the source repos. [17:22] rtg: even linus version apply ok [17:22] [flag@luxor ubuntu-saucy]$ git cherry-pick -sx f091578 [17:22] [master-next acaa3ca] ARM: tlb: don't perform inner-shareable invalidation for local TLB ops Author: Will Deacon 3 files changed, 123 insertions(+), 30 deletions(-) [17:22] ppisati, ok, works for me then [17:22] anyhow [17:22] let's wait until it builds [17:23] ppisati, isn't that the same SHA1 as rmk tree ? f091578 and f0915781bd5edf78b1154e61efe962dc15872d09 [17:23] same sha [17:24] ppisati, ok, I see what I did. I got the wrong patch, e.g., 'ARM: tlb: don't perform inner-shareable invalidation for local BP' [17:24] rtg: yeah, slightly different subj [17:24] rtg: local BP vs local TLB [17:24] ppisati, too damn close... === fmasi is now known as fmasi_afk === fmasi_afk is now known as fmasi [18:10] rtg: sent [18:10] ppisati, ack === fmasi is now known as fmasi_afk [20:54] apw: hey, can you sanity check me... does fsync() have any meaning on ptys? [21:01] slangasek, i cannot think what it would mean on a pty [21:01] hmm [21:01] the data is either in the hole or it is not [21:02] so I'm asking because of https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-upstart/14/ARCH=amd64,label=adt/ - an upstart test that's failed intermittently, because a log file that's supposed to be created didn't get created [21:02] and I'm trying to figure out why; my current guess is in-kernel buffering [21:03] but that's a SWAG [21:03] the other possibility is the kernel is doing everything right, and upstart is just failing to create the logfile with the data it's meant to be reading from the pty ;) [21:08] slangasek, if you can point me at the source for the test, i'll have a think about it and figure out if fsync means anything [21:10] apw: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/upstart/trusty/view/head:/init/tests/test_state.c#L2115 vs. http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/upstart/trusty/view/head:/init/tests/test_state.c#L2143 [21:12] anyway, fsync() returns non-zero, so in practice that's the wrong interface anyway ;) [22:04] * rtg -> EOW