BarkingFishok guys, well I'm gonna have to head out. jsalisbury - if you see this, I'll stop by some other time - but I'm needed in ER, so I'm out for the night. See ya00:16
jussihrm, Im on 12.10 and a kernel update is giving me issues. tbh, I quite scare to restart the machine...  paste of apt-get install -f http://paste.ubuntu.com/1615272/06:53
jussiits way too early in the morning, so forgive me if it is something simple06:54
ashwini_Can any one tell me the default stack size for kernel 3.x and 2.6.y (y < 31)???07:14
=== amitk is now known as amitk-afk
ppisatigood morning Viet^W^W^W^Wworld07:39
* jussi hugs ppisati and bribes him with coffee and breakfast for some help :D07:47
ppisatijussi: what's up?07:48
jussi[08:53:39] <jussi> hrm, Im on 12.10 and a kernel update is giving me issues. tbh, I quite scare to restart the machine...  paste of apt-get install -f http://paste.ubuntu.com/1615272/07:48
jussi[08:54:36] <jussi> its way too early in the morning, so forgive me if it is something simple07:48
ppisatijussi: gzip: stdout: No space left on device07:49
jussippisati: errr? this is my laptop... is that /boot ? or just my HDD  is full (shouldnt be...)07:50
ppisatijussi: dunno, df -h will tell you07:50
ppisatijussi: but i guess is /boot07:50
jussi/dev/sda1                   228M  226M     0 100% /boot07:50
jussiso I guess old kernels need moving on then? 07:51
ppisatidpkg -l | grep linux-image07:51
ppisatijussi: i think you know what to do from here07:52
jussippisati: yeah, I think so. --purge them, right? 07:52
ppisatijussi: except for the running one, yes07:53
jussippisati: what are the -extra images? 07:54
ppisatijussi: stuff that was moved out of linux-image07:54
ppisatijussi: dpkg -L will tell you07:54
jussithanks ppisati, much appreciated.07:57
=== smb` is now known as smb
=== amitk-afk is now known as amitk
caribouwhere is the linux-meta package maintained ? In launchpad or somewhere in the kernel tree ?09:16
smbcaribou, neither. In a git repo seperate to the kernel09:16
caribousmb: and how one propose a patch ? (can you see the linux-crashdump dependency on kdump-tools coming ;-) ) ?09:17
smbcaribou, Right, I actually was thinking of submitting that soon09:18
caribousmb: ok, then, I won't bother09:18
caribousmb: afaik, once this is done, kdump-tools should be pulled in main09:18
caribousmb: since linux-crashdump will depend on it, and the makedumpfile source is already in main09:19
smbcaribou, Not sure how strict dependency issues are for a meta package but it sounds reasonable to have those things that are core functions in main09:20
caribousmb: don't know about meta package either, I can check 09:21
ashwini_any clue regarding default stack size in the kernel 3.x and 2.6.28+ ?09:21
smbcaribou, Talking to apw it sounds like having the dependency in meta will require some parts to be in main. Just not sure whether this can only be the source package or not. So maybe that should be resolved before changing the meta package.09:29
smbcaribou, Just as for what needs to be in main and what would that mean (mostly security updates? and would we think there are?)09:30
caribousmb: I just pinged pitti in #ubuntu-devel; he seems to think so09:30
caribousmb: well, the security updates would make it in from makedumpfile which is already in main anyway, isn't it ?09:31
smbcaribou, From that side yes. Guess the only thing I can think of right now is the tools placing dumps with not enough limited access...09:32
apwashwini_, i belive they can be either 4K or 8K on x86 I believe we use 8K but i am struggling to find the confirmation09:44
apwashwini_, THREAD_SIZE is the relevant define09:47
ashwini_apw: THREAD_SIZE is 8k, I belive in new kernels the stack size is 4k instead of 8k. just want to confirm once. Any way Thanks09:49
apwashwini_, in v3.8-rc's it seems unchanged09:49
ashwini_apw : is STACK size 8k ? or THREAD_SIZE 8k ? any link?09:50
apwTHREAD_SIZE is 8K, which is the kernel stack size, which is documented in kernel source in Documention/x86/x86_64/kernel-stacks and obviously set in the arch specific headers in the source09:51
apwarch/x86/include/asm/page_32_types.h:#define THREAD_SIZE_ORDER  109:52
apwarch/x86/include/asm/page_64_types.h:#define THREAD_SIZE_ORDER  109:52
apwhere defined in allocator order, 0 == 4K 1 == 8K on x8609:52
=== henrix_ is now known as henrix
ashwini_apw : Thanks, your help and pointers much appreciated10:13
ashwini_apw: it resolved my lot of doubts10:13
ogra_apw, one for us to test (later today) http://nv-tegra.nvidia.com/gitweb/?p=chromeos/kernel.git;a=commitdiff;h=b50bf5979036750891461a5824bb12273f04fe16 ... from bug 108078910:50
ubot2Launchpad bug 1080789 in ubuntu-nexus7 "Corruption around mouse cursor when dragged, particularly around Dash, Indicators, window chrome" [Low,Confirmed] https://launchpad.net/bugs/108078910:50
apwogra_, sigh11:09
ogra_apw, no hurry for that one, itr only exposes if you have a mouse attached to the tablet, thats rather low prio and can well wait until the next upload happens anyway11:24
* ppisati notices there's sun outside and goes out for lunch11:45
smbsun... lucky bastard11:48
apwogra_, that patch looks to be from a completely different kernel version, cirtainly none of the things it changes seem to exist11:57
apwogra_, after a fair bit of looking i cannot trivially find anything remotly similar to apply it by hand12:42
ogra_apw, ok13:05
apwogra_, i recon it would be appropriate to do the testing as recommended in the bug13:14
apwogra_, it can only eliminate something13:14
AlexMGHi guys, I was trying to use the fetch=url parameter, to netboot filesystem from the ubuntu-livecd. But it seems as the fetch parameter is just ignored. Are changes needed inside the initrd or do I just use the wrong kernel options? KERNEL-Options loaded from iPXE: kernel boot=casper config fetch=
ogra_well, the kernel patch is for consoles, which dont work at all anyway (you cant switch to console once X is up, restriction of the driver )13:15
ogra_so i guess we can as well skip it13:16
* henrix wanders if something killed a ppc build or it was a genuine build failure13:27
rtg_herton, henrix: did you notice the Quantal PPC FTBS ?13:29
henrixrtg_: yep, i was just complaining about that :)13:29
henrixrtg_: no idea what went wrong there...13:30
henrixi guess i'll just retry13:30
hertonhenrix, it's a build failure in alx driver13:30
rtg_henrix, looks like a bonafide linker error13:30
herton /build/buildd/linux-3.5.0/ubuntu/alx/alx_main.c: In function 'alx_alloc_rings':13:30
henrixherton: oh, crap! you're right13:31
henrixlooks like its failing only on ppc. amd64, i386 and armhf are fine13:32
henrixwhich doesnt' make sense13:32
apwhenrix, could be believeable if it is a locking primative or similar which was changed between working and not; those are arch specific13:37
apwhenrix, and have arch specific external symbol requirements13:37
henrixapw: yep. i'm rebuilding it in gomeisa as i deleted the build logs, just to make sure.13:38
apwhenrix, or indeed that driver may be only on in PPC13:39
apwhenrix, and isn't that a driver which was applied like only Feb 0413:40
henrixapw: yep, that's the one13:40
apwhenrix, i don't see how this is valid on any release13:43
apwas it blatently uses vzmalloc without includeing vmalloc.h13:43
henrixapw: yeah, so maybe you're right: it may be built only for ppc. i'm investigating13:44
henrixapw: so, my theory is that one of the headers included by the alx driver will bring net/ip6_checksum.h and linux/vmalloc.h on some archs but not for powerpc14:26
henrixapw: if you look at the buildlogs for amd64 for example, the driver compiles successfully14:27
henrixapw: i'll test a patch on a ppc box that will just include these 2 headers (that should be in the driver anyway)14:28
rtg_henrix, I think perhaps you could just disable the alx driver build for all but x86'en14:28
henrixrtg_: well, that's another solution. would you prefer that? i guess it will be useless in ppc anyway14:29
rtg_henrix, Its the simplest.14:29
henrixrtg_: ack, will do that then. thanks14:29
* henrix -> errand15:06
* ogasawara back in 2015:35
henrixrtg_: fyi i'm going to apply the alx patch to Q master-next15:49
rtg_henrix, already did15:49
henrixrtg_: heh, cool. thanks15:49
rtg_jjohansen, henrix, rebooting tangerine for kernel update15:57
henrixrtg_: ack15:58
jjohansenrtg_: okay, give me one minute15:58
jjohansenhehe, or not15:58
rtg_jjohansen, go ahead15:58
jjohansenrtg_: no I'm good, I just wanted to make sure my editor was closed and saved, but I had already done that15:58
slangasekhi, can anyone here tell me if there's more debugging info that would be useful from the running process on bug #1117499, before I kill with fire?16:58
ubot2Launchpad bug 1117499 in linux (Ubuntu) "killall -9 firefox fails to work in raring" [Critical,New] https://launchpad.net/bugs/111749916:58
slangasekbjf: ^^ any thoughts on this madness?17:00
ohsixwould want to see the process state and wchan17:03
slangasekohsix: shown how?17:04
ohsix/proc/<pid>/wchan, top displays it i think17:05
ohsixif it's waiting on something in the kernel it will have a name, it wouldn't be unkillable unless it's in a syscall that won't exit17:06
slangasekwell, seems to be state 'R' - not state 'D' which is what I would normally expect to see for an unkillable process?17:07
=== sabayonuser3 is now known as Tuxkalle
slangasekso I guess the next question is, can I kill the X server or is it similarly wedged17:09
ohsixthere's no transitive property of signal-undelivery between firefox and X or any other process i know of17:11
ohsixwhat's perf top say firefox is doing17:11
slangasekbut the firefox and X processes seem to be in a similarly useless state17:11
slangasek(using lots of CPU according to top, but not using it for anything I would like it to)17:11
slangasekohsix: I don't have perf installed and apt offers me two choices - linux-base and linux-tools-common.  Does it matter which I take?17:12
slangasekoh, looks like one of these might be a ghost and linux-tools-common is the right one17:12
ohsixit's in linux-tools-common17:12
rtg_slangasek, should be linux-tools-common17:12
slangaseker, except it isn't in fact17:13
slangasekpackaging bug?17:13
ohsixi got that same offer after a reinstall, didn't look into why it suggested linux-base; there's a wrapper script and a versioned binary to go with the kernel, i'm guessing they moved around a little17:13
infinityslangasek: linux-tools-$(uname -r)17:13
ohsixperf_<tab> :)17:13
slangasek$ dpkg -L linux-tools-common | grep perf17:13
slangasekinfinity: ta17:13
infinityErr, or not.17:14
slangasekinfinity: minus the -generic :)17:14
infinityThere's a "linux-tools" metapackage that deals with that. :P17:14
slangaseker, that doesn't have it *either*17:14
infinityNo, it sure doesn't... Did we disable perf again, due to libaudit deps?17:15
rtg_slangasek, infinity - I think so due to build issues. lemme recheck it17:15
slangaseklinux (3.8.0-0.2) raring; urgency=low17:16
slangasek  * [packaging] Add macro to selectively disable building perf17:16
slangasek  * [packaging] Cannot depend on universe package libaudit-dev17:16
infinityIt may be high time for us to just MIR audit.17:16
rtg_infinity, right, that kind of fell off my radar.17:16
slangasekinfinity: it's been requested before but stalled for some reason I don't recall... I think I talked to jdstrand about it a while ago, maybe sync with him?17:16
slangasekI think we do want to get audit into main though, yeah17:16
infinityYeah, there's been more than one MIR attempt for audit, IIRC.17:16
infinityBut a ton of stuff depends on it these days.17:17
infinity(even glibc)17:17
slangasekpam wants it too17:17
slangasekand systemd of course17:17
ubot2Ubuntu bug 1026852 in audit (Ubuntu) "[MIR] audit (pulls in libprelude)" [Undecided,New]17:18
ohsixso you can't run perf? that's awesome17:18
infinitySo, yeah, that's been stalled.  I'll poke the relevant folks.17:18
ppisatiguess what?17:35
* ppisati -> gym17:36
slangasekPenn and Taler17:37
slangasekso, firefox finally saw fit to die on its own17:42
slangasekX is still frozen though17:42
ohsixif it really was not responding to SIGKILL, it finally was able to exit whatever syscall it was in _if_ thats' what it was, there's not much else you can do to keep SIGKILL from being delivered17:45
=== chiluk is now known as chiluk_away
=== henrix is now known as henrix_
=== henrix_ is now known as henrix
* rtg_ burns a couple hours catching up with LKML18:26
* rtg_ -> lunch18:28
zequenceI have a problem with my debian/rules file. Meaning to update linux-lowlatency for precise. This is what happens:18:31
zequencefakeroot debian/rules clean18:31
zequencedebian/rules.d/0-common-vars.mk:10: *** first argument to `word' function must be greater than 0.  Stop.18:31
zequenceBeen googling a bit, but I might need more stuff to go through all of it18:32
zequenceapw: Something with the debian folder in lowlatency seems to be wacky. What would be the best way for me to circumvent this problem18:33
apwzequence, i think that might be caused by a corrupt versionlog18:37
apwzequence, check debian.lowlatency/changelog hasn't got wacked any18:37
apwzequence, ahh are you using the fixed version i published ?  18:38
apwzequence, i had to remove a blank line from your changelog to be able to upload it18:38
apwcommit 9a282dd2cd0f7c85f62dea5fe8221940e26a061218:38
apwAuthor: Andy Whitcroft <apw@canonical.com>18:38
apwDate:   Mon Jan 28 09:31:19 2013 +000018:38
apw    UBUNTU: fix up blank lines in changelog18:38
apwzequence, i bet it is that which is breaking you, pull from the 'public' repo: git://kernel.ubuntu.com/apw/ubuntu-precise-lowlatency.git18:39
zequenceapw: Oh. Thanks. Will try that18:40
zequenceapw: Hope I didn't cause you too much trouble. I baked in your commit, updated, and pushed linux-precise-lowlatency19:05
apwzequence, sweet19:07
apwwill look at it later thanks19:07
=== chiluk_away is now known as chiluk
infinityapw: Your linux-lowlatency is missing a build-dep on openssl19:28
infinityapw: (Master has it, you might want to double-check if anything else is missing)19:29
=== chiluk is now known as chiluk_away
=== chiluk_away is now known as chiluk
=== henrix is now known as henrix_
* rtg_ -> EOD20:45
=== chiluk is now known as chiluk_away
=== chiluk_away is now known as chiluk
=== chiluk is now known as chiluk_away
=== chiluk_away is now known as chiluk
apwinfinity, thanks23:29
infinityapw: I'd have pointed it out when I fixed powerpc, but I didn't realise lowlatency was similarly broken. :P23:31

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!