[02:27] Hello. Im trying to compile an ubuntu kernel for the first time, and I'm running into a problem with a video driver for the platform im compiling for [02:27] I'd like to know how to go about stopping the make process from trying to compile this driver [02:29] MadBoat: Best bet for questions like this is #ubuntu [02:30] alright. on what server? [02:30] Im an IRC newbie as well, sorry if thats newb question [02:36] MadBoat: this server [02:36] K. much obliged [06:24] moin [06:26] morning ppisati [07:06] cking and ppisati, morning [07:06] hiya cooloney [07:06] cking: got your email. [07:07] ack [07:07] cking: looks like we still don't have any clue to decide the change [07:08] maybe we need some input from ubuntu server folks [07:10] ciao * :) [07:10] ppisati: how's going? and your usb issue on beaglexm [07:11] cooloney, as long as they don't provide us with untested "gut feeling" preferences that don't consider recent kernels [07:11] * cking just likes hard facts [07:13] cking: right, we need reproduce the issue firstly and try more test case. [07:18] morning [07:18] smb: morning [07:19] cking: i just was told they got a lot of writing operation timeout when using CFQ in cluster server. but have no idea to test this or reproduce it. [07:20] cooloney, Was that the same bug report as that one being done on a kvm? [07:20] (which I did not yet have luck in reproducing) [07:21] smb: hmm, i don't think so. just some description from them, i also want some hard facts like cking [07:21] Right, I agree changing anything based on no facts makes no sense [07:22] cooloney: saw ming's email? i'm gonna try that now [07:22] smb: yeah, on my side, i just have an 3 years old desktop, no chance to do some fancy testing [07:22] cooloney: after that i'll see for smsc911xx phy deinit code [07:22] ppisati: yeah, worth a try. [07:22] I can rig up more tests if required [07:22] cooloney: but the problem is that, after kexec, the entire usb hub is dead [07:23] cooloney: so IMO the problem is one layer below all these drivers [07:23] ppisati: i saw several patches from ming about usbnet, but might not related to kexec [07:23] cooloney, Heh, actually one feels as really old hardware is ideal. That makes the disk output even slower. :) [07:23] cooloney: but let me first try ming's mfd patch [07:23] cooloney: if it revives the usb, then the rest might be worth a try [07:24] ppisati: right, ming is good for help ^^ [07:26] cooloney, But anyway. If your friends could open bug reports and provide a bit more information about the setup and what fails where (and maybe you then subscribe me to those) then we can start gathering facts [07:27] yep, the more data the better [07:30] smb, cking, right, and which testcase or benchmark tool is good for parallel reads and writes [07:30] all and none of them [09:52] Can anyoen tell me what is the status of the new poulsbo driver in Ubuntu? is it in Precise/Quantal? Does it do 3D? [10:41] Kernel image taxonomy: is the "generic" flavour for i386/amd64 analogous to ARM subarches? So if I had a architecture-aware hierarchy, would it be fair to use / and end up with amd64/generic and armhf/highbank without any collisions or confusion? [10:44] * ppisati -> out for lunch [12:42] apw: ping [12:43] hi [12:43] apw: remember the ddeb that you rebuilt for me a few days back [12:44] apw: I just found out that, while working well with crash dumps, it causes problem with systemtap [12:44] yay ... its good job we don't support those versions :) [12:44] what sort of problems does it cause [12:46] well the Build-id mismatch that I got from systemtap on a rebuilt ddeb (both by you and arges_) doesn't appear on the original ddebs [12:46] caribou, is that related to any bugs ? [12:46] well frankly they are rebuilt, and the stamp is likley wrong [12:46] and never can be right [12:46] I had kept a .tgz copy of the original ddeb (the one that was on the archives) and this one works [12:47] apw: I could open a bug on this, but it mostly concern systemtap. Just thought I'd mention it [12:47] the build stamps likely include the date and time of the build ... [12:47] i don't think anyone will fix it as clearly you are asking for trouble to not use the ddebs which were made with the kernel you are debugging; it is correct to tell you its wrong [12:47] apw, would there be a way to extract this from the .deb and insert into the rebuilt .ddeb ... or perhaps allow the debugging tools to ignore the time stamp difference [12:48] you probabally should look to makeing the tool continue --i-know-i-am-using-the-wrong-ddeb [12:48] note sure it's the timestamp. might be coming from the ELF notes [12:48] arges_, you should not be looking to do thing routinly, you should be retaining the old ddebs if you are supporting unsuported kernel versiosn [12:49] apw, unfortunately the natty kernel ddebs were already deleted before we had a chance to back them up [12:49] the tool is right to tell you off, as there really is no guarentee the info is even right [12:49] and we're working on crashes that involve natty [12:49] you have ddebs for the support kernel versions even in natty [12:50] and the old ones, they are gone, and they arn't recoverable [12:50] apw: arges_ the code that triggers the Build-id mismatch is runtime code triggered by systemtap [12:50] caribou, arges_ i have to reiterate there is almost no chance they are completely accurate debugging symbols if rebuilt; the compiler is not the same most likely [12:51] given systemtap is dropping code over the kernel code segment live while its running, i am not supprised it is reticent to do so with debug info which is dubious [12:51] apw: I know. I Just wanted to make you all aware of this. But looks pretty good for crash dump analysis [12:51] indeed i think i would prefer systemtap refuse and have no way to let you [12:52] apw: could this be caused by the fact that the ddebs were done on a newer distro (i.e. diffs in elf or such) ? [12:52] as patching a live running system which it will likely lead to pain [12:52] caribou, they were built in appropriate chroots, but ones which were up to date [12:52] apw: you know how support engineers like pain... [12:52] heh they do indeed [12:53] apw: I have a Natty server available; I'll try to rebuild the kernel on it and see if there is a difference [12:54] caribou, you'd need to find out what kernel the buildd that ran on was running, and get a chroot which represents the chroot which was there on that day [12:54] and even then you'd not be guarenteed to make anything the same [12:54] make sure toolchain was at the same version [12:54] apw: yeah, I know. Which is why keeping the ddebs around is so important [12:55] apw: arges_ well they were the ones used by you guys when you built the Natty official kernels [12:56] apw: arges_ does it worth opening a new bug for this ? Maybe systemtap should take that into account ? [13:01] caribou, i don't think systemtap can take into account "you don't have reliable ddeb offset infromation for your running kernel" its black and white, its either right or its not [13:02] apw: yeah, right. Shouldn't build broken contexts into the tool. Agree === ikonia is now known as ikonia_ === ikonia_ is now known as ikonia === ogra_ is now known as ogra === ogra is now known as ogra_ [14:15] smb, around? [14:15] smoser, yes [14:15] potentially stupid question. [14:16] * smb likes those [14:16] i'm looking at https://bugs.launchpad.net/nova/+bug/832507 [14:16] Ubuntu bug 832507 in nova "console.log grows indefinitely" [Medium,In progress] [14:16] i just launched a kvm guest, and did: [14:17] sudo dd if=/dev/zero bs=1M count=4 of=/dev/console [14:17] 4194304 bytes (4.2 MB) copied, 43.3846 s, 96.7 kB/s [14:17] so, it seems that /dev/console is limited (for my kvm instance) at < 100kB/s [14:18] kvm process seems pegged handling that. [14:18] (cpu pegged) [14:18] the concerning thing to me is that the kernel writes data on boot at a rate not far off that [14:19] ie, in the console log that i have (http://paste.ubuntu.com/1042460/), the kernel wrote that ~15k in .75 seconds. [14:19] that woudl seem to indicate to me that [14:20] a.) a fair amount of cpu resources during my bootup were spent in kvm reading the console writes [14:20] b.) the kernel potentially blocked and waited some time on those writes [14:20] i'm hoping/expecting that you can tell me that 'b' is not true, that the printk messgaes writing would not block anything else really. [14:20] smb, ^ [14:23] smoser, Not sure I know the whole chain from the top of my head. But printk's first go into the kernel ring buffer [14:24] smoser, smb: isn't it syslog that pulls out the dmesg ? [14:24] tgardner, well this is to /dev/console specifically [14:24] ie, 'console=/dev/ttyS0' or 'console=/dev/console' [14:25] tgardner, I think that is for the files in /var/log [14:25] i did not think that syslog was involved there. [14:25] ok, likely not [14:25] But I think there is something else to send them to consoles... [14:26] (asynchronously) [14:26] apw, Would you know that from your head? ^ [14:28] right there is a bit of printk which pumps out the pending bits if there is a 'console' attached to dmesg [14:29] so probably 'b' is not a terrible concern. ie, those writes are not going to slow down boot [14:30] if you have a slow serial it can indeed slow down boot if its attached to dmesg [14:30] smoser, I wonder what happens if the console backs up [14:30] the backlog gets emitted when the console gets attached [14:40] * ogasawara back in 20 [14:42] tgardner, I'm going start to apply here 3.0.34/3.2.20 to oneiric/precise master-next [14:42] herton, ack [14:44] herton, I did just push precise master-next, so you should refresh first [14:44] tgardner, ok [14:49] smoser, So it looks like printk tries to output to the console(s) first but can go (and leave things in a buffer) if the lock cannot bet taken... So I would read that as the boot is not slowed down... [14:52] yeah, at least not significantly. [14:52] thanks [14:52] Could someone confirm that a debugger process (with >=1 children being ptraced) loses ptrace rights if *it* execs. [14:53] I may be off track, but since fs/binfmt_elf.c:load_elf_binary() eventually calls ptrace_unlink(), I believe such a process does lose knowledge of its debugees. [16:22] * smb` thinks it is about time drop [16:34] * cking agrees with smb [16:34] * cking --> EOD [17:26] tgardner, fixed up that pull request .. let me know if there are other issues [17:26] arges, you reposted on the list ? [17:27] tgardner, yea [17:34] arges, while the ssh:// patch works for me, its not very helpful for non-Canonical emps. I prefer that you use the git:// form of the path (but I've pulled anyways) [17:34] tgardner, shoot [17:34] tgardner, meant to use that [17:36] arges, s/shoot/darn/ Tim's from Montana ;-) [17:36] arges: also, its BugLink, not BugFix in the commit log. you can use kteam-tools/maintscripts/maint-modify-patch to slam in bug numbers, acks, etc. [17:37] jsalisbury, heh [17:37] tgardner, ok will use that from now on [17:37] tgardner, should i resubmit it? [17:37] arges, nah, I'll fix 'em up when I get a second ACK [17:38] tgardner, ok. thanks. [17:38] * arges takes some notes. === tgardner is now known as tgardner-lunch === arges is now known as arges_lunch [17:57] I feel silly for asking this, but can someone point me to a means to get the Precise kernel installed on a Lucid system? [18:03] bladernr_, you can get the .debs from: https://launchpad.net/ubuntu/+source/linux/3.4.0-5.11 [18:03] just look under "Builds" for your arch [18:03] ahhh... cool, thanks. I was looking for a backports package but the latest available is oneiric [18:03] jsalisbury: thanks! [18:04] bladernr_, whoops thats quantal, precise can be downloaded from: [18:04] https://launchpad.net/ubuntu/+source/linux/3.2.0-25.40 [18:04] bladernr_: we don't backport one LTS to another [18:05] bjf: ahhh, that would explain it :) === tgardner-lunch is now known as tgardner [18:21] bjf, thats just for the last LTS cycle. we'll eventually backport 14.04 to 12.04. [18:23] tgardner: whatever you say === arges_lunch is now known as arges [18:40] herton, hello. i see your comment about my pineview cherry pick... do you need me to rebase and reapply to and test? [18:40] to lucid [18:40] arges, no, not needed, it was a message more to tgardner when he is going to apply it [18:41] herton, ok in the future, should i be basing my SRUs against master-next instead of master? [18:41] arges, preferably yes, although hardly we could get some clash I think (something that applies to master but not master-next) [18:42] ok noted. [18:52] * ogasawara lunch === tgardner is now known as tgardner-EOD [22:50] Hi! I reported this bug #997767. Anyone who can advise on what I can do? [22:50] Launchpad bug 997767 in linux "10ec:8139 Network connection rtl8139 lost after some hours of inactivity and comes up again on user interaction" [Medium,Incomplete] https://launchpad.net/bugs/997767 [22:55] luca, i'll add a comment to the bug [22:56] bjf: Thanks. I don't want to bother you guys. Just want to know if I can do anything. Nothing seems to solve, not even recovery mode. [22:57] luca, unfortunately, friday afternoon is a bad time to pop into the channel and ask for help. what timezone are you in? [22:58] bjf: I know that, sorry, I'm GMT+2:0 but I work during the day so I can only work on this in my free time. [22:59] luca, wasn't intended as a criticism, just stating the obvious [22:59] bjf: yes, I understand, just giving a try :-) thanks for your help! [23:01] luca, is it about 1am where you are right now ? [23:01] bjf: yes, 1am now. [23:02] luca, what i'd suggest is on monday after you get home from work or whatever, there will be a lot of folks around that live in the U.S. [23:02] luca, several of them have a lot more experience with wifi issues than i do [23:03] luca, i could help you bisect your kernel but i'm not convinced that is the issue [23:03] bjf: not wifi here, just old eth. Anyway thanks! I'll try on monday then! Yes, I don't think that either. Older kernel should work I guess... [23:03] luca, i'm not saying it's not a kernel issue [23:04] luca, sorry i didn't get that [23:05] luca, you were running oneiric just fine with no issues? [23:05] bjf: yes [23:06] bjf: never had an issue. [23:06] huh [23:06] and now you've updated, have the issue. even if you run the oneiric kernel on your precise install [23:06] bjf: exactly [23:07] bjf: tested many times. [23:09] bjf: I'll test again with a live CD of 12.04 and 11.10 and see what happens. I don't have any other idea. recovery mode fails as well so I don't know what might be the cause. [23:10] luca, some of what you describe makes it seem like a userspace isssue [23:10] luca, please do come back monday and we'll try to help you out [23:11] bjf: yes, but I don't know exactly what recovery mode runs. Thank you very much! [23:13] luca: when testing the latest mainline kernels, did you also install the linux-image-extra-* package? [23:13] jwi: no, should I? [23:14] luca: yes - this is most likely what's causing the boot failures. [23:14] jwi: then I'll test again installing that as well. Thanks!