[02:27] <MadBoat> 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] <MadBoat> I'd like to know how to go about stopping the make process from trying to compile this driver
[02:29] <BenC> MadBoat: Best bet for questions like this is #ubuntu
[02:30] <MadBoat> alright. on what server?
[02:30] <MadBoat> Im an IRC newbie as well, sorry if thats newb question
[02:36] <BenC> MadBoat: this server
[02:36] <MadBoat> K. much obliged
[06:24] <ppisati> moin
[06:26] <cking> morning ppisati
[07:06] <cooloney> cking and ppisati, morning
[07:06] <cking> hiya cooloney
[07:06] <cooloney> cking: got your email. 
[07:07] <cking> ack
[07:07] <cooloney> cking: looks like we still don't have any clue to decide the change 
[07:08] <cooloney> maybe we need some input from ubuntu server folks
[07:10] <ppisati> ciao * :)
[07:10] <cooloney> ppisati: how's going? and your usb issue on beaglexm
[07:11] <cking> 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] <cooloney> cking: right, we need reproduce the issue firstly and try more test case. 
[07:18] <smb> morning
[07:18] <cooloney> smb: morning
[07:19] <cooloney> 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] <smb> cooloney, Was that the same bug report as that one being done on a kvm?
[07:20] <smb> (which I did not yet have luck in reproducing)
[07:21] <cooloney> smb: hmm, i don't think so. just some description from them, i also want some hard facts like cking
[07:21] <smb> Right, I agree changing anything based on no facts makes no sense
[07:22] <ppisati> cooloney: saw ming's email? i'm gonna try that now
[07:22] <cooloney> smb: yeah, on my side, i just have an 3 years old desktop, no chance to do some fancy testing
[07:22] <ppisati> cooloney: after that i'll see for smsc911xx phy deinit code
[07:22] <cooloney> ppisati: yeah, worth a try.
[07:22] <cking> I can rig up more tests if required
[07:22] <ppisati> cooloney: but the problem is that, after kexec, the entire usb hub is dead
[07:23] <ppisati> cooloney: so IMO the problem is one layer below all these drivers
[07:23] <cooloney> ppisati: i saw several patches from ming about usbnet, but might not related to kexec
[07:23] <smb> cooloney, Heh, actually one feels as really old hardware is ideal. That makes the disk output even slower. :)
[07:23] <ppisati> cooloney: but let me first try ming's mfd patch
[07:23] <ppisati> cooloney: if it revives the usb, then the rest might be worth a try
[07:24] <cooloney> ppisati: right, ming is good for help ^^
[07:26] <smb> 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] <cking> yep, the more data the better
[07:30] <cooloney> smb, cking, right, and which testcase or benchmark tool is good for parallel reads and writes 
[07:30] <cking> all and none of them
[09:52] <jussi> 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] <rbasak> 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 <arch>/<flavour> and end up with amd64/generic and armhf/highbank without any collisions or confusion?
[10:44]  * ppisati -> out for lunch
[12:42] <caribou> apw: ping
[12:43] <apw> hi
[12:43] <caribou> apw: remember the ddeb that you rebuilt for me a few days back
[12:44] <caribou> apw: I just found out that, while working well with crash dumps, it causes problem with systemtap
[12:44] <apw> yay ... its good job we don't support those versions :)
[12:44] <apw> what sort of problems does it cause
[12:46] <caribou> 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] <arges_> caribou, is that related to any bugs ?
[12:46] <apw> well frankly they are rebuilt, and the stamp is likley wrong
[12:46] <apw> and never can be right
[12:46] <caribou> I had kept a .tgz copy of the original ddeb (the one that was on the archives) and this one works
[12:47] <caribou> apw: I could open a bug on this, but it mostly concern systemtap. Just thought I'd mention it
[12:47] <apw> the build stamps likely include the date and time of the build ...
[12:47] <apw> 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] <arges_> 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] <apw> you probabally should look to makeing the tool continue --i-know-i-am-using-the-wrong-ddeb
[12:48] <caribou> note sure it's the timestamp. might be coming from the ELF notes
[12:48] <apw> 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] <arges_> apw, unfortunately the natty kernel ddebs were already deleted before we had a chance to back them up
[12:49] <apw> the tool is right to tell you off, as there really is no guarentee the info is even right
[12:49] <arges_> and we're working on crashes that involve natty
[12:49] <apw> you have ddebs for the support kernel versions even in natty
[12:50] <apw> and the old ones, they are gone, and they arn't recoverable
[12:50] <caribou> apw: arges_ the code that triggers the Build-id mismatch is runtime code triggered by systemtap
[12:50] <apw> 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] <apw> 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] <caribou> apw: I know. I Just wanted to make you all aware of this. But looks pretty good for crash dump analysis
[12:51] <apw> indeed i think i would prefer systemtap refuse and have no way to let you
[12:52] <caribou> 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] <apw> as patching a live running system which it will likely lead to pain
[12:52] <apw> caribou, they were built in appropriate chroots, but ones which were up to date
[12:52] <caribou> apw: you know how support engineers like pain...
[12:52] <apw> heh they do indeed
[12:53] <caribou> 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] <apw> 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] <apw> and even then you'd not be guarenteed to make anything the same
[12:54] <arges_> make sure toolchain was at the same version
[12:54] <caribou> apw: yeah, I know. Which is why keeping the ddebs around is so important
[12:55] <caribou> apw: arges_ well they were the ones used by you guys when you built the Natty official kernels
[12:56] <caribou> apw: arges_ does it worth opening a new bug for this ? Maybe systemtap should take that into account ?
[13:01] <apw> 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] <caribou> apw: yeah, right. Shouldn't build broken contexts into the tool. Agree
[14:15] <smoser> smb, around?
[14:15] <smb> smoser, yes
[14:15] <smoser> potentially stupid question.
[14:16]  * smb likes those
[14:16] <smoser> i'm looking at https://bugs.launchpad.net/nova/+bug/832507
[14:16] <ubot2> Ubuntu bug 832507 in nova "console.log grows indefinitely" [Medium,In progress]
[14:16] <smoser> i just launched a kvm guest, and did:
[14:17] <smoser>  sudo dd if=/dev/zero bs=1M count=4 of=/dev/console
[14:17] <smoser> 4194304 bytes (4.2 MB) copied, 43.3846 s, 96.7 kB/s
[14:17] <smoser> so, it seems that /dev/console is limited (for my kvm instance) at < 100kB/s
[14:18] <smoser> kvm process seems pegged handling that.
[14:18] <smoser> (cpu pegged)
[14:18] <smoser> the concerning thing to me is that the kernel writes data on boot at a rate not far off that
[14:19] <smoser> ie, in the console log that i have (http://paste.ubuntu.com/1042460/), the kernel wrote that ~15k in .75 seconds.
[14:19] <smoser> that woudl seem to indicate to me that
[14:20] <smoser> a.) a fair amount of cpu resources during my bootup were spent in kvm reading the console writes
[14:20] <smoser> b.) the kernel potentially blocked and waited some time on those writes
[14:20] <smoser> 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] <smoser> smb, ^
[14:23] <smb> 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] <tgardner> smoser, smb: isn't it syslog that pulls out the dmesg ?
[14:24] <smoser> tgardner, well this is to /dev/console specifically
[14:24] <smoser> ie, 'console=/dev/ttyS0' or 'console=/dev/console'
[14:25] <smb> tgardner, I think that is for the files in /var/log
[14:25] <smoser> i did not think that syslog was involved there.
[14:25] <tgardner> ok, likely not
[14:25] <smb> But I think there is something else to send them to consoles...
[14:26] <smb> (asynchronously)
[14:26] <smb> apw, Would you know that from your head? ^
[14:28] <apw> right there is a bit of printk which pumps out the pending bits if there is a 'console' attached to dmesg
[14:29] <smoser> so probably 'b' is not a terrible concern. ie, those writes are not going to slow down boot
[14:30] <apw> if you have a slow serial it can indeed slow down boot if its attached to dmesg
[14:30] <tgardner> smoser, I wonder what happens if the console backs up
[14:30] <apw> the backlog gets emitted when the console gets attached
[14:40]  * ogasawara back in 20
[14:42] <herton> tgardner, I'm going start to apply here 3.0.34/3.2.20 to oneiric/precise master-next
[14:42] <tgardner> herton, ack
[14:44] <tgardner> herton, I did just push precise master-next, so you should refresh first
[14:44] <herton> tgardner, ok
[14:49] <smb> 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] <smoser> yeah, at least not significantly.
[14:52] <smoser> thanks
[14:52] <jodh> Could someone confirm that a debugger process (with >=1 children being ptraced) loses ptrace rights if *it* execs.
[14:53] <jodh> 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] <arges> tgardner, fixed up that pull request .. let me know if there are other issues
[17:26] <tgardner> arges, you reposted on the list ?
[17:27] <arges> tgardner, yea
[17:34] <tgardner> 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] <arges> tgardner, shoot
[17:34] <arges> tgardner, meant to use that
[17:36] <jsalisbury> arges, s/shoot/darn/   Tim's from Montana ;-)
[17:36] <tgardner> 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] <arges> jsalisbury, heh
[17:37] <arges> tgardner, ok will use that from now on
[17:37] <arges> tgardner, should i resubmit it?
[17:37] <tgardner> arges, nah, I'll fix 'em up when I get a second ACK
[17:38] <arges> tgardner, ok. thanks.
[17:38]  * arges takes some notes.
[17:57] <bladernr_> 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] <jsalisbury> bladernr_, you can get the .debs from: https://launchpad.net/ubuntu/+source/linux/3.4.0-5.11
[18:03] <jsalisbury> just look under "Builds" for your arch
[18:03] <bladernr_> ahhh... cool, thanks.  I was looking for a backports package but the latest available is oneiric
[18:03] <bladernr_> jsalisbury: thanks!
[18:04] <jsalisbury> bladernr_, whoops thats quantal, precise can be downloaded from:
[18:04] <jsalisbury> https://launchpad.net/ubuntu/+source/linux/3.2.0-25.40
[18:04] <bjf> bladernr_: we don't backport one LTS to another
[18:05] <bladernr_> bjf: ahhh, that would explain it :)
[18:21] <tgardner> bjf, thats just for the last LTS cycle. we'll eventually backport 14.04 to 12.04.
[18:23] <bjf> tgardner: whatever you say
[18:40] <arges> herton, hello. i see your comment about my pineview cherry pick... do you need me to rebase and reapply to and test?
[18:40] <arges> to lucid
[18:40] <herton> arges, no, not needed, it was a message more to tgardner when he is going to apply it
[18:41] <arges> herton, ok in the future, should i be basing my SRUs against master-next instead of master?
[18:41] <herton> arges, preferably yes, although hardly we could get some clash I think (something that applies to master but not master-next)
[18:42] <arges> ok noted.
[18:52]  * ogasawara lunch
[22:50] <luca> Hi! I reported this bug #997767. Anyone who can advise on what I can do?
[22:50] <ubot2> 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] <bjf> luca, i'll add a comment to the bug
[22:56] <luca> 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] <bjf> luca, unfortunately, friday afternoon is a bad time to pop into the channel and ask for help. what timezone are you in?
[22:58] <luca> 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] <bjf> luca, wasn't intended as a criticism, just stating the obvious
[22:59] <luca> bjf: yes, I understand, just giving a try :-) thanks for your help!
[23:01] <bjf> luca, is it about 1am where you are right now ?
[23:01] <luca> bjf: yes, 1am now.
[23:02] <bjf> 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] <bjf> luca, several of them have a lot more experience with wifi issues than i do
[23:03] <bjf> luca, i could help you bisect your kernel but i'm not convinced that is the issue
[23:03] <luca> 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] <bjf> luca, i'm not saying it's not a kernel issue
[23:04] <bjf> luca, sorry i didn't get that
[23:05] <bjf> luca, you were running oneiric just fine with no issues?
[23:05] <luca> bjf: yes
[23:06] <luca> bjf: never had an issue.
[23:06] <bjf> huh
[23:06] <bjf> and now you've updated, have the issue. even if you run the oneiric kernel on your precise install
[23:06] <luca> bjf: exactly
[23:07] <luca> bjf: tested many times.
[23:09] <luca> 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] <bjf> luca, some of what you describe makes it seem like a userspace isssue
[23:10] <bjf> luca, please do come back monday and we'll try to help you out
[23:11] <luca> bjf: yes, but I don't know exactly what recovery mode runs. Thank you very much!
[23:13] <jwi> luca: when testing the latest mainline kernels, did you also install the linux-image-extra-* package?
[23:13] <luca> jwi: no, should I?
[23:14] <jwi> luca: yes - this is most likely what's causing the boot failures.
[23:14] <luca> jwi: then I'll test again installing that as well. Thanks!