=== rsalveti` is now known as rsalveti [05:03] anybody know if the new (2.6.35+) rc-core-based kernel modules can by used to do ir blaster stuff? i want to transmit ir codes through a homebrew serial ir blaster without using lircd. [07:37] moin [07:37] ppisati, morning [07:37] ppisati, good morning! [07:38] <_jmp_> morning ppisati smb cking [08:24] moin [08:30] more coffee... [09:08] anybody know if the new (2.6.35+) rc-core-based kernel modules can by used to do ir blaster stuff? i want to transmit ir codes through a homebrew serial ir blaster without using lircd. [09:55] * ppisati is melting... [09:58] * abogani is wondering about where exactly ppisati is melting .. [12:20] * ppisati -> lunch === yofel_ is now known as yofel [14:18] herton, hello [14:18] arges, hi [14:19] herton, about the systemtap bug. you mentioned using --only-keep-debug, would this be for reducing the size of the ddebs or for another purpose? [14:19] arges, just for reducing the size. I think we don't strip the debug .ko's at the moment, I did a quick look and didn't found anything [14:21] herton, ok maybe that's something to do for future work. i think its a good idea since the ddebs are very large. [14:22] arges, yes, I agree, just noticed we could be stripping and keeping only the debug symbols while looking at that change [14:23] ok [14:40] * ogasawara back in 20 [14:41] ok everyone, its that time of the day again, where smoser exposes his grave ignorance! [14:42] i'm thinking about bug 1016695 [14:42] Launchpad bug 1016695 in cloud-init "add console=tty0 to cloud-image kernel boot parameters" [Wishlist,New] https://launchpad.net/bugs/1016695 [14:43] summary is that upstart messages (and stdout of 'console output' jobs it starts) go to the /dev/console device. [14:43] and getting that console device set to the right place is kind of difficult if you're targetting a one-size-fits-all image (like the cloud-images). [14:44] i can think of 2 possible ways of making this nicer. [14:45] a.) some kernel "tee device" that would take writes to /dev/console and just write to multiple devices (ie, what 'tee file1 file2 file3' would do) [14:45] b.) some way to more intelligently set where writes to /dev/console end up. [14:46] smb, any thoughts? [14:47] smoser, Yes, I think that I need to think about it but feel like saying no-way to a) [14:48] yeah, kernel tee device probably isn't the right place, as we could probably get the same with a user-land fifo. it just takes another process. [14:52] smoser, The early boot messages probably not (until any user-space is up). But from looking last and some experiments, through you can have console= multiple times, the kernel has some "preferred" console concept and that likely is there for a reason. [14:53] smb, right. multiple console= is acceptable and nice. [14:53] and it generlly selects the last entry in the parameters to tie to /dev/console [14:53] i'm not sure what happens if hte last entry is non-existant (ie, 'console=ttyS0' when there is no ttyS0. i think it probably does at least somethign sane). [14:54] so basically... the kernel does a pretty good job, but after init is started its more complex. [14:54] (this is where you probably say to me "not my problem" :) ) [14:57] Heh, probably. Well, I wonder what could be done in syslog config... I believe there is now a single line for it, but maybe that could also become multiple... Though I would want to play around before I boldly state such a thing [15:06] smoser, Hm, ok, so reading this through more carefully it sounds more like something that whatever carries on with console output from init/upstart would need the concept of multiple consoles. syslogd is no good there and the kernel handles it that way (just /dev/console is always just one console) [15:09] smb, right. bsaically, init (upstart) would have to hook the processes' stdout, stderr to something that it (or some other "tee like thing") then wrote to multiple places. [15:13] smoser, Otherwise the only other option would be to make cloud-init test various options and then modify the command line for the next boot. If having the first boot not show then is acceptable [15:13] next boot is useless. [15:13] but yeah, that is easy[er] [15:15] hrm, libreoffice spreadsheet kinda chokes on > 90K samples in a graph, need more memory :-) [15:15] cking, you should use something more powerful then an Atom. [15:15] Not sure whether that part of upstart could be more knowledgable than to just go for console. But then there will always be cases (ok maybe not with images on the cloud) where ttyS0 is present but unused... [15:16] rtg, I'm using an i5 @ 2.6GHz with 6 GB [15:16] smb, well, present but unused is fine. [15:16] cking, that seems like it ought to be enough [15:16] not for the graphs I'm crunching [15:16] ie, i dont really care about writing to additional places. just, ideally, want to make sure that if someone goes looking for messages, they see them. [15:17] smoser, I guess not when you have a Xen guest with a serial defined... You still would want to use hvc0 [15:17] yeah, its difficult. [15:17] :) [15:18] i think that the best thing to do would be to write a bunch of places, basically anything likely to be watched that is available. [15:18] and to have init mimic that basic behavior [15:19] smoser, Yes, true. Which at the current state of things really would make me say not so much my problem because the kernel messages do go multiple ways. I know that is evasive... ;) [15:20] smb, well, the only issue ihave with the kernel behavior is that i have to load up the command line manually with a bunch of "likely" places. [15:20] * cking spots a trend which means he has to re-do a bunch of tests, *sigh* [15:20] and i'm not aware of the behavior if the last one in the list happens to be non-existant. [15:21] ie: 'console=tty0 console=ttyS0 console=hvc0' without a hvc0 [15:25] smoser, probably does the right thing (though it should be tested). One drawback is that the more you have there more load/delay there may be. But then you cannot make this work for everyone in all cases. [15:27] smoser, Even assuming this can be changed at some point from user-space, it is probably only the guest configuration on the host that would be able to say what the console is and I am not sure all possible virtualisation types would provide some way to find out... [15:33] smb, yeha. i didn't htink there was any clear simple way to get this right. [15:33] but, thanks for your input. [15:52] rtg, any idea how to list subsribed multicast groups ? [15:52] apw, not from memory [15:52] apw, would there be anything in dmesg ? [15:53] * apw finds it by luck [15:53] rtg, ip maddr does it [15:53] apw, makes sense [15:58] apw: hi. Did you happen to see my email about kernel oopses a little while back? [16:05] ev, do we normally get cores from crashes, that'd not be a common config [16:06] and something we'd not want to be sending anywhere somewhere i suspect [16:06] ah, interesting. What are you looking for, and what would be a reasonable algorithm for the signature of it? [16:07] there is a common oops format in dmesg/messages [16:07] we are sending those in already though right, in the apport enabled world [16:07] oh I'm misreading my own email [16:07] right [16:07] indeed, we are sending oopses through [16:08] but we don't have a signature for them [16:08] i'd assume signatures could be done the way you do them for any other C style applkication [16:08] the only special is there are ? entries which generally can be ignored [16:08] thus my proposal of ext4_get_acl+0x80/0x210:d_splice_alias+0x40/0x50:ext4_check_acl+0x4a/0x90:acl_permission_check+0x97/0xa0:generic_permission+0x25/0xc0:inode_permission+0x99/0xd0 for https://launchpadlibrarian.net/79771442/OopsText.txt [16:08] right [16:10] you might also want to include the type of the blammo [16:11] so thats a 'kernel paging request' [16:11] apw: okay, will do. And you're happy with the rest of that as a signature? [16:11] with the type included, that is [16:13] ev, yeah i think until we try it we're not going to see what triggers overly commonisation or over differntiation [16:13] fair point [16:13] ev, when you do other C things do you include the +xx parts ? [16:14] apw: until we have a fully retraced stacktrace, yes: http://people.canonical.com/~ubuntu-archive/apport-duplicates/address/_usr_bin_Thunar_6 [16:21] * ppisati -> gym [16:22] apw: out of curiosity, why don't we want to capture VmCore files? [16:22] its not a simple thing to do, and not enabled by default [16:23] as your machine has to crash and reboot to do it, we normally try and hang one and keep going, for least supprise [16:23] ah, understood [16:24] and the chances of the vmcore not having something sensitive in it is very small [16:28] apw: thanks for all the advice [16:28] ev thanks for looking at it === rtg is now known as rtg-lunch [18:36] apw, I've now collected and graphed way too much data for the low-latency kernel and I'll try and get it written up tomorrow. I find the data still rather perplexing [18:38] cking, that sounds 'bad' [18:39] the results kind of match what we expect in some cases, but not in others, which I find perplexing === rtg-lunch is now known as rtg [18:52] * ppisati -> out for dinner [18:56] Hi, how do i disable a option in config file for compiling...is it a 'n' or a '0" or a m ?, also can someone help me with fixing up a config file for minimum size vanilla version [19:17] laserbled, its # CONFIG_FOO is not set [19:18] apw, great, do I have to comment it out using # too ? [19:20] ok, I am assuming that doesn't resolve as a comment then [19:21] # CONFIG_FOO is not set [19:21] is a specific syntax meaning =n [19:23] apw, yes, got it. can you tell me what does a m stand for ? [19:23] modular [19:26] apw, great. thanks a lot for the info. [19:28] np [20:58] * rtg -> EOD [21:57] ogasawara, do you have the bug number for the arm fix we may try to include? [21:57] skaet: didn't fill them yet [21:57] skaet: i'll do it now [21:57] thanks ppisati :) [22:16] skaet: bug 1017717 [22:16] Launchpad bug 1017717 in linux "Severe filesystem corruption on beagle board" [Undecided,New] https://launchpad.net/bugs/1017717 [22:16] skaet: bug 1017718 [22:16] Launchpad bug 1017718 in linux "Usb hub not working on beagle board" [Undecided,New] https://launchpad.net/bugs/1017718 [22:16] ogasawara: ^^ [22:17] thanks ppisati. What should the priorities be for these? [22:18] first one is already fixed (i've the patch here) for the second one i'm still investigating one thing (and i hope to clear it ASAP...) [22:18] * skaet noticing Undecided, New and figures they're probably In Progress , High [22:18] ah right, forgot the status [22:18] right [22:18] in progress, high is good [22:22] ppisati, have noted it on the bugs.