| 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:27 |
| BenC | MadBoat: Best bet for questions like this is #ubuntu | 02:29 |
| MadBoat | alright. on what server? | 02:30 |
| MadBoat | Im an IRC newbie as well, sorry if thats newb question | 02:30 |
| BenC | MadBoat: this server | 02:36 |
| MadBoat | K. much obliged | 02:36 |
| ppisati | moin | 06:24 |
| cking | morning ppisati | 06:26 |
| cooloney | cking and ppisati, morning | 07:06 |
| cking | hiya cooloney | 07:06 |
| cooloney | cking: got your email. | 07:06 |
| cking | ack | 07:07 |
| cooloney | cking: looks like we still don't have any clue to decide the change | 07:07 |
| cooloney | maybe we need some input from ubuntu server folks | 07:08 |
| ppisati | ciao * :) | 07:10 |
| cooloney | ppisati: how's going? and your usb issue on beaglexm | 07:10 |
| 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:11 | |
| cooloney | cking: right, we need reproduce the issue firstly and try more test case. | 07:13 |
| smb | morning | 07:18 |
| cooloney | smb: morning | 07:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| cooloney | ppisati: right, ming is good for help ^^ | 07:24 |
| 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:26 |
| cking | yep, the more data the better | 07:27 |
| 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 | 07:30 |
| 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? | 09:52 |
| 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:41 |
| * ppisati -> out for lunch | 10:44 | |
| caribou | apw: ping | 12:42 |
| apw | hi | 12:43 |
| caribou | apw: remember the ddeb that you rebuilt for me a few days back | 12:43 |
| 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:44 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| caribou | apw: arges_ well they were the ones used by you guys when you built the Natty official kernels | 12:55 |
| caribou | apw: arges_ does it worth opening a new bug for this ? Maybe systemtap should take that into account ? | 12:56 |
| 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:01 |
| caribou | apw: yeah, right. Shouldn't build broken contexts into the tool. Agree | 13:02 |
| === ikonia is now known as ikonia_ | ||
| === ikonia_ is now known as ikonia | ||
| === ogra_ is now known as ogra | ||
| === ogra is now known as ogra_ | ||
| smoser | smb, around? | 14:15 |
| smb | smoser, yes | 14:15 |
| smoser | potentially stupid question. | 14:15 |
| * 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:23 |
| 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:24 |
| 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:25 |
| smb | (asynchronously) | 14:26 |
| smb | apw, Would you know that from your head? ^ | 14:26 |
| apw | right there is a bit of printk which pumps out the pending bits if there is a 'console' attached to dmesg | 14:28 |
| smoser | so probably 'b' is not a terrible concern. ie, those writes are not going to slow down boot | 14:29 |
| 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:30 |
| * ogasawara back in 20 | 14:40 | |
| 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:42 |
| tgardner | herton, I did just push precise master-next, so you should refresh first | 14:44 |
| herton | tgardner, ok | 14:44 |
| 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:49 |
| 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:52 |
| 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. | 14:53 |
| * smb` thinks it is about time drop | 16:22 | |
| * cking agrees with smb | 16:34 | |
| * cking --> EOD | 16:34 | |
| 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:26 |
| arges | tgardner, yea | 17:27 |
| 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:34 |
| 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:36 |
| 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:37 |
| arges | tgardner, ok. thanks. | 17:38 |
| * arges takes some notes. | 17:38 | |
| === tgardner is now known as tgardner-lunch | ||
| === arges is now known as arges_lunch | ||
| 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? | 17:57 |
| 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:03 |
| 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:04 |
| bladernr_ | bjf: ahhh, that would explain it :) | 18:05 |
| === tgardner-lunch is now known as tgardner | ||
| tgardner | bjf, thats just for the last LTS cycle. we'll eventually backport 14.04 to 12.04. | 18:21 |
| bjf | tgardner: whatever you say | 18:23 |
| === arges_lunch is now known as arges | ||
| 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:40 |
| 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:41 |
| arges | ok noted. | 18:42 |
| * ogasawara lunch | 18:52 | |
| === tgardner is now known as tgardner-EOD | ||
| 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:50 |
| bjf | luca, i'll add a comment to the bug | 22:55 |
| 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:56 |
| bjf | luca, unfortunately, friday afternoon is a bad time to pop into the channel and ask for help. what timezone are you in? | 22:57 |
| 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:58 |
| 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! | 22:59 |
| bjf | luca, is it about 1am where you are right now ? | 23:01 |
| luca | bjf: yes, 1am now. | 23:01 |
| 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:02 |
| 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:03 |
| bjf | luca, sorry i didn't get that | 23:04 |
| bjf | luca, you were running oneiric just fine with no issues? | 23:05 |
| luca | bjf: yes | 23:05 |
| 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:06 |
| luca | bjf: tested many times. | 23:07 |
| 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:09 |
| 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:10 |
| luca | bjf: yes, but I don't know exactly what recovery mode runs. Thank you very much! | 23:11 |
| 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:13 |
| 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! | 23:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!