| === steve__ is now known as sbeattie | ||
| === gfrog_ is now known as gfrog | ||
| === AceLan_ is now known as AceLan | ||
| apw | hallyn_, heh you should indeed | 11:03 |
|---|---|---|
| === fmasi_afk is now known as fmasi | ||
| alex116 | hi, I'm trying to read i2c data and from userspace the example code uses ioctl | 13:05 |
| alex116 | I want to read i2c data from a kernel module and would like to figure out how to read from the device | 13:06 |
| alex116 | can I just use the normal open read write close functions? | 13:06 |
| cking | alex116, how about https://www.kernel.org/doc/Documentation/i2c/dev-interface | 13:12 |
| === kentb is now known as kentb-afk | ||
| === fmasi is now known as fmasi_afk | ||
| cking | maybe https://www.kernel.org/doc/Documentation/i2c/writing-clients | 13:35 |
| === fmasi_afk is now known as fmasi | ||
| alex116 | I was hoping I could just use the loaded driver's functions because thats all ioctl does | 14:10 |
| igalic | 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:41 |
| infinity | zequence: It's SRU time again, if you missed out on the new bugs. | 14:44 |
| infinity | igalic: There's no reason it would remove them unless you ask it to remove something they depend on. | 14:44 |
| infinity | igalic: As a general rule, people are expected to read apt's output when it tells them what it intends to do. | 14:44 |
| apw | infinity, arn't they even manually installed top levels so it should be hard to force them off | 14:45 |
| apw | igalic, how did you get into a sitruation where it wanted to, what did you ask for | 14:46 |
| apw | that it though could only be solved by so removing it | 14:46 |
| infinity | apw: They're manually installed, yeah. Not that autoremove would ever pull them anyway, since they're never installed as deps. | 14:47 |
| infinity | apw: So, people removing them are doing it intentionally (ie: by removing the kernel they depend on) | 14:47 |
| apw | i can only assume you asked it to remove the latest kernel ? | 14:47 |
| igalic | 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:47 |
| igalic | (I like how the automatic section is actually empty) | 14:48 |
| igalic | oh.. that's the latest kernel. That's why it's removing it. | 14:51 |
| igalic | so that "documentation" is lying. | 14:52 |
| diwic | 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:53 |
| ogasawara | diwic: most likely 3.13 | 14:54 |
| diwic | ogasawara, thanks, that was my guess too | 14:54 |
| rtg | apw, dropped 'UBUNTU: SAUCE: (no-up) drm -- stop early access to drm devices' during the rebase. Do you think we still need it ? | 14:56 |
| === fmasi is now known as fmasi_afk | ||
| infinity | igalic: "apt-get autoremove" will not remove the running kernel. Random other weird snippets on wikis are generally suspect. | 15:01 |
| igalic | infinity: apt-get autoremove will not remove the running kernel, but it will remove the running kernel's utils, tools and headers. | 15:02 |
| infinity | igalic: Not anymore. | 15:02 |
| apw | rtg, i think i am supprised to still find it applied, i thought that that was fixed another way in upstream now | 15:02 |
| rtg | apw, well, I've been faithfully forward porting it for several releases | 15:03 |
| infinity | igalic: That was fixed in saucy. In precise, it'll yank tools probably, yeah. Maybe also headers. | 15:03 |
| apw | rtg, hehe ... oh well ... | 15:03 |
| apw | infinity, didn't we fix those deps back in the end? i thought we did | 15:03 |
| rtg | apw, guess we'll find out. I haven't even boot tested this pile yet | 15:03 |
| igalic | infinity: that's badd, because we're running LTS | 15:04 |
| infinity | apw: I may have made the header fix in precise. Can't fix the tools issue without backporting the rename/reorg. | 15:04 |
| igalic | infinity: can you link me to the bug? | 15:04 |
| === kentb-afk is now known as kentb | ||
| apw | infinity, point, that we have done for the lts-backport kernels, saucy onwards but .. yes not before that | 15:04 |
| infinity | igalic: Okay, just verified, precise won't autoremove headers, but it will autoremove tools. | 15:05 |
| === fmasi_afk is now known as fmasi | ||
| infinity | igalic: And the tools problem is hard to solve without us reorganizing the precise kernel packages. | 15:05 |
| infinity | (Which is probably not worth doing with another LTS around the corner, IMO) | 15:05 |
| infinity | Given that the number of people who need tools installed is tiny. | 15:05 |
| igalic | perf top is invaluable. | 15:06 |
| infinity | For normal users? | 15:06 |
| igalic | >_o | 15:07 |
| infinity | You and I may define normal differently. :P | 15:07 |
| igalic | Define normal users. | 15:07 |
| infinity | s/normal/average/ | 15:07 |
| infinity | Statistically, very few people use perf. | 15:07 |
| igalic | I'm a Unix Admin. I don't know what you mean. | 15:07 |
| infinity | 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:07 |
| igalic | Yes, except we have everything puppetized on hundreds of machines. | 15:08 |
| infinity | Anyhow, we *could* backport the whole tool renaming madness to precise, I'm just not sure it's worth the pain. | 15:08 |
| igalic | infinity: if I run the cool new kernels on LTS, will that still be an issue? | 15:09 |
| infinity | apw: Is the tool renaming magic represented in linux-lts-saucy? | 15:10 |
| igalic | i.e.: linux-image-generic-lts-saucy | 15:10 |
| * infinity looks. | 15:10 | |
| igalic | (or any other) | 15:10 |
| apw | infinity, yes | 15:10 |
| infinity | Yeah, looks like that works. | 15:10 |
| apw | infinity, oh well ... perhaps the answer is "in the new one" | 15:11 |
| infinity | igalic: Only lts-saucy, not the earlier ones. | 15:11 |
| infinity | But, I'd need to backport the matching apt fix for that. | 15:11 |
| apw | it may not have hit updates yet, or is about to now or something | 15:11 |
| igalic | infinity: apw: can you link me to the issues describing this? | 15:11 |
| infinity | 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:11 |
| infinity | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1205284 | 15:12 |
| ubot2 | Launchpad bug 1205284 in linux (Ubuntu Precise) "linux-tools naming is not scalable to multiple source packages" [Medium,Fix committed] | 15:12 |
| apw | 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:12 |
| apw | infinity, yeah the wrapper fixes are pending for the next sru round for master | 15:13 |
| infinity | apw: s/next/current/, or in another month? | 15:13 |
| apw | as in only on master-next right now | 15:13 |
| infinity | Bummer. Well, I'll backport the apt fix, since that's trivial. | 15:14 |
| apw | ie the /usr/bin/perf won't recognise the new perf binaries till that fgoes out | 15:14 |
| apw | yeah, it got missed in testing | 15:14 |
| apw | its not like you cannot find them manually so not world ending, they are there installed | 15:14 |
| infinity | apw: Alright, apt backport uploaded. | 15:18 |
| igalic | wowzers! | 15:18 |
| infinity | 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 |
| igalic | infinity: do you have a bug for that also I can track? | 15:19 |
| infinity | igalic: Same bug I pasted above. | 15:19 |
| igalic | 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:23 |
| ppisati | bjf: i'm preparing the P/omap4 kernel | 15:25 |
| bjf | ppisati, ack | 15:25 |
| * ppisati disappears for a bit | 15:28 | |
| infinity | igalic: If you want headers too, that would be linux-generic-lts-saucy | 15:30 |
| infinity | igalic: And linux-tools-generic-lts-saucy for tools. | 15:30 |
| igalic | infinity: linux-generic-lts-saucy installs headers also? | 15:30 |
| infinity | igalic: "linux-generic" depends on "linux-image-generic" and "linux-headers-generic" (trade "generic" for flavour du jour, like generic-lts-saucy) | 15:31 |
| igalic | infinity: I think I've asked this question a couple of times, but, what's the difference between -generic, -server, -chewgum, -etc ? | 15:31 |
| infinity | 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:32 |
| infinity | igalic: But, on LTSes, you'll have different generic options for the HWE backport kernels (like lts-raring, lts-saucy, etc). | 15:33 |
| infinity | Oh, I guess it's not fair to say "generic" is the only one, as there's also lowlatency. | 15:33 |
| infinity | But it's the only one built from the master sources. :P | 15:33 |
| igalic | What's that mean? | 15:34 |
| infinity | There's a "linux" source package, maintained by the Canonical kernel team, and it only produces the generic (and virtual) flavour. | 15:35 |
| apw | (and notionally the server flavour) | 15:35 |
| infinity | 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 |
| infinity | apw: There is no server flavour. | 15:35 |
| infinity | (Not anymore) | 15:36 |
| apw | there is a linux-server and linux-{image,headers}-server though | 15:36 |
| apw | which are used in server images, which is why it is notional | 15:36 |
| infinity | apw: Sure, but it just installs generic. ;) | 15:37 |
| apw | right, just .. dunoo ... being a pedant | 15:37 |
| infinity | I suppose it keeps the option open if we feel the need to fork configs again some day. | 15:37 |
| infinity | But with scheduler improvements and the like, forked configs are less interesting over time. | 15:37 |
| igalic | It would be nice to install -server and have sysctl settings actually worthy of a server. | 15:37 |
| apw | igalic, that would be possible, as it has its own meta package | 15:38 |
| apw | igalic, if there was a definative set which made sense | 15:38 |
| igalic | apw: disabling the oom killer for instance ;) | 15:43 |
| apw | 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:45 |
| infinity | Disabling the OOM killer doesn't magically prevent you from running out of RAM. | 15:49 |
| infinity | 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 |
| igalic | No, it doesn't but it magically prevents the kernel from not killing processes even though I'm NOT out of RAM. | 15:50 |
| infinity | igalic: When you're out of RAM, all your processes are out of RAM. Until a sufficiently large one crashes. *shrug* | 15:51 |
| infinity | 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:51 |
| infinity | 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:52 |
| infinity | igalic: You can't control WHICH process hits the last available page and dies. | 15:53 |
| igalic | please read http://www.twistedmatrix.com/users/glyph/rant/softethics.html | 15:53 |
| apw | your point with that ? | 15:54 |
| apw | or is that a total no-sequiter | 15:54 |
| infinity | apw: It's unethical to prevent init(8) from dying, if that's what it chose to do. | 15:54 |
| infinity | apw: How dare we stand in the way of its suicide attempt via malloc(). | 15:55 |
| apw | igalic, anyhow if you can change it via sysclt, one can do that, so ... | 15:55 |
| igalic | apw: read the bit about car manufacturers. | 15:57 |
| igalic | (I think a good resource is also http://www.loper-os.org/?p=284 ) | 15:59 |
| infinity | 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? | 15:59 |
| infinity | 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:00 |
| igalic | I think a better "fuel" analogy is this one https://lwn.net/Articles/104179/ ;) | 16:01 |
| apw | so all one needs to do is swtich to full commit mode for allocation and ensure you have enough swap | 16:03 |
| igalic | And suddenly you have a predictable VM. YAY. It's almost like I'm using a Unix. | 16:04 |
| apw | yeha right, like they wern't the same | 16:06 |
| === fmasi is now known as fmasi_afk | ||
| === fmasi_afk is now known as fmasi | ||
| ppisati | rtg: i'm building a test kernel | 17:09 |
| rtg | ppisati, ack, I'm about to email a comment to robher about the mac learning patch | 17:10 |
| TooLmaN | 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:12 |
| ppisati | [flag@luxor ubuntu-saucy]$ git fetch origin | 17:16 |
| ppisati | [flag@luxor ubuntu-saucy]$ git rhard origin/master-next | 17:16 |
| ppisati | HEAD is now at a223125 UBUNTU: SAUCE: (no-up) apparmor: Fix tasks not subject to, reloaded policy | 17:16 |
| ppisati | [flag@luxor ubuntu-saucy]$ git cherry-pick -sx f0915781bd5edf78b1154e61efe962dc15872d09 | 17:16 |
| ppisati | [master-next 15fa8df] ARM: tlb: don't perform inner-shareable invalidation for local TLB ops Author: Will Deacon <will.deacon@arm.com> 3 files changed, 123 insertions(+), 30 deletions(-) | 17:16 |
| ppisati | rtg: ^ | 17:16 |
| ppisati | rhard is an alias for 'reset --hard' | 17:16 |
| rtg | ppisati, huh, well maybe I fat fingered something. | 17:17 |
| ppisati | rtg: actually that hash comes from rmk's git tree | 17:17 |
| rtg | ppisati, well, try the same patch from Linus' tree | 17:18 |
| ppisati | rtg: but if you don't have that remote, it would probably say 'unknown hash or something' | 17:18 |
| ppisati | rtg: let's see | 17:18 |
| TooLmaN | disregard. I had to add the source repos. | 17:21 |
| ppisati | rtg: even linus version apply ok | 17:22 |
| ppisati | [flag@luxor ubuntu-saucy]$ git cherry-pick -sx f091578 | 17:22 |
| ppisati | [master-next acaa3ca] ARM: tlb: don't perform inner-shareable invalidation for local TLB ops Author: Will Deacon <will.deacon@arm.com> 3 files changed, 123 insertions(+), 30 deletions(-) | 17:22 |
| rtg | ppisati, ok, works for me then | 17:22 |
| ppisati | anyhow | 17:22 |
| ppisati | let's wait until it builds | 17:22 |
| rtg | ppisati, isn't that the same SHA1 as rmk tree ? f091578 and f0915781bd5edf78b1154e61efe962dc15872d09 | 17:23 |
| ppisati | same sha | 17:23 |
| rtg | 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 |
| ppisati | rtg: yeah, slightly different subj | 17:24 |
| ppisati | rtg: local BP vs local TLB | 17:24 |
| rtg | ppisati, too damn close... | 17:24 |
| === fmasi is now known as fmasi_afk | ||
| === fmasi_afk is now known as fmasi | ||
| ppisati | rtg: sent | 18:10 |
| rtg | ppisati, ack | 18:10 |
| === fmasi is now known as fmasi_afk | ||
| slangasek | apw: hey, can you sanity check me... does fsync() have any meaning on ptys? | 20:54 |
| apw | slangasek, i cannot think what it would mean on a pty | 21:01 |
| slangasek | hmm | 21:01 |
| apw | the data is either in the hole or it is not | 21:01 |
| slangasek | 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 |
| slangasek | and I'm trying to figure out why; my current guess is in-kernel buffering | 21:02 |
| slangasek | but that's a SWAG | 21:03 |
| slangasek | 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:03 |
| apw | 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:08 |
| slangasek | 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:10 |
| slangasek | anyway, fsync() returns non-zero, so in practice that's the wrong interface anyway ;) | 21:12 |
| * rtg -> EOW | 22:04 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!