| === k-s is now known as k-s[AWAY] | ||
| === __Purple__ is now known as _Purple_ | ||
| === thunderstruck is now known as gnomefreak | ||
| === mdz_ is now known as mdz | ||
| === thunderstruck is now known as gnomefreak | ||
| === k-s[AWAY] is now known as k-s | ||
| === k-s is now known as k-s[AWAY] | ||
| === k-s[AWAY] is now known as k-s | ||
| === k-s is now known as k-s[AWAY] | ||
| Shock | hi, I have changed a config option, built source package with "debuild -S" and uploaded the package to launchpad. the build fails with "EE: Previous or current ABI file missing!". how can I fix this? | 13:53 |
|---|---|---|
| rtg | pgraner: CONFIG_USB_SERIAL=y bug number? | 14:40 |
| === k-s[AWAY] is now known as k-s | ||
| manjo | smb_tp, the kernel prints out so much info that its hard to run the suspend resume tests with it | 14:54 |
| smb_tp | manjo, Ok, feared so much. I remove most of it and get you something lighter | 14:55 |
| manjo | smb_tp, also I could not figure out what it was printing coz it was printing so much stuff... | 14:55 |
| manjo | so looks like the drive reports ready but still in EBUSY state | 14:55 |
| smb_tp | manjo, Yeah, I turned on the verbose debugging, but saw it probably is too much | 14:56 |
| manjo | it happens when you suspend without power cord attach and attach the power cord after you suspend and then resume with the power cord still plugged in | 14:56 |
| manjo | if you give me a clue I can put some debug printfs | 14:57 |
| smb_tp | Hm, thats interesting | 14:57 |
| manjo | do you have any hints ? | 14:58 |
| manjo | I think I found some points where I want to print info reading the code yesterday | 14:58 |
| smb_tp | I need to play around this anyways as we want/need some debugging there. But I would start around the soft/hard reset functions | 14:58 |
| manjo | now I have a fair understanding of libata stuff to start putting printfs | 14:58 |
| manjo | smb_tp, yeah that is what I had in mind | 14:59 |
| smb_tp | Won't prevent you from doing that then. :) | 14:59 |
| manjo | :) | 15:00 |
| tjaalton | apw: hi, what about bug 224642, any chance to get it in before the freeze? | 15:04 |
| === nturner_ is now known as nturner | ||
| rtg | tjaalton: lest you feel ignored, apw just asked me if he could push the patch for that bug. | 15:14 |
| apw | rtg thanks ... just got bounced from the network :( | 15:15 |
| apw | tjaalton, thanks for the prod. i've pushed that change up and it should make the kernel | 15:17 |
| manjo | apw, smb_tp did we cancel the meeting for today? | 15:19 |
| apw | hrm, we cirtainly didn't actually do anything to cancel it | 15:19 |
| smb_tp | I thought I had written an email... | 15:19 |
| manjo | smb_tp, yeah see that | 15:21 |
| manjo | thansk | 15:21 |
| tjaalton | rtg, apw: great, thanks! | 15:44 |
| === k-s is now known as k-s[AWAY] | ||
| === k-s[AWAY] is now known as k-s | ||
| liw | sysklogd looks for a symbol matching Version_[0-9]+ in System.map, but Ubuntu (intrepid, jaunty) doesn't seem to include one; Debian (lenny) does; anyone know what's up? | 18:59 |
| liw | this is related to #277924 | 18:59 |
| lool | liw: We had one in /boot/System.map-2.6.24-19-generic; perhaps something which was dropped upstream? | 19:03 |
| liw | I don't have a changelog.Debian that reaches that far back in time, only to 2.6.26-2.6 | 19:09 |
| infinity | liw: What kernel version is lenny shipping that has this symbol? | 19:10 |
| liw | infinity, 2.6.26 | 19:10 |
| infinity | liw: Ahh, hrm. In the LP bug, all the reported METOOs are from 2.6.27+, so it may well be an upstream change. | 19:11 |
| liw | infinity, would you be able to easily check that? | 19:14 |
| infinity | I have no local git love here. Haven't worked on the Ubuntu kernel in ages. :/ | 19:14 |
| infinity | So, no, not any more readily than you could. | 19:14 |
| infinity | liw: There's a random claim from Russell King that on kernels with KALLSYMS, we should be invoking klogd with "-x" to skip the System.map lookup entirely. | 19:18 |
| infinity | liw: But, we had KALLSYMS=y back in hardy too, where it seemed to work fine. | 19:19 |
| smb_tp | liw, Hm, what do you mean exactly by Intrepid and Jaunty do not have a System.map? | 19:21 |
| liw | smb_tp, they don't have a symbol that matches Version_[0-9]+ in their System.map, which is what sysklogd wants to find | 19:22 |
| liw | in order to figure out which kernel version the map is for, I think | 19:22 |
| smb_tp | liw, Ah, ok. Got it | 19:22 |
| liw | infinity, indeed, in my hardy VM, with 2.6.24, System.map is correctly loaded and the symbols it there | 19:23 |
| liw | I haven't had any real understanding about building kernels since 0.97 or so, so I'm a bit lost here | 19:23 |
| infinity | liw: Well, I'd begin by a violent recursive grep of the hardy kernel source for the string "Version_", find out where the symbol comes from, then check intrepid/jaunty to see if that codepath went away, or if we're accidentally optimising it away with a certain config option. | 19:25 |
| smb_tp | infinity, yeah. currently looking | 19:25 |
| infinity | liw: Out of curiosity, does this missing symbol (and klogd not getting to load System.map) actually lead to any real bugs, or just ugly log output? :P | 19:27 |
| liw | infinity, that's a good question :) | 19:27 |
| infinity | liw: I mean, I'd assume it prevents klogd from doing pointer lookups to name symbols... But I have no idea why we'd care. | 19:27 |
| infinity | liw: Assuming that programs that actually make use of System.map (modutils, ksymoops, that sort of thing) are parsing it correctly, I'm not entirely sure that the klogd thing matters at all, and maybe we should just be invoking it with "-x" to skip the System.map read entirely. | 19:30 |
| infinity | -x Omits EIP translation and therefore doesn’t read the System.map file. | 19:30 |
| smb_tp | I would think that missing the right System.map has simmilar effect | 19:31 |
| liw | if we don't care about System.map being found by sysklogd, we don't need to do anything, really | 19:32 |
| smb_tp | But since I already saw stack traces with symbol names there must be an alternate way | 19:32 |
| infinity | smb_tp: Oh, I'm sure the end result is the same, just that one avoids an Sky is Falling error message. :) | 19:32 |
| infinity | smb_tp: I suspect the symbol names are coming from KALLSYMS=y | 19:32 |
| infinity | smb_tp: (As noted, users of KALLSYMS should be loading klogd with -x anyway) | 19:32 |
| infinity | liw: Optionally, if you can find a clever way to detect KALLSYMS is in effect, you could patch klogd to print a friendlier "KALLSYMS kernel loaded, skipping System.map load", instead of "OH GOD, NO SYSTEM.MAP, HALP!" | 19:33 |
| liw | infinity, I think I'd rather see someone who understands what you just said do that :) | 19:34 |
| smb_tp | infinity, that would be a plausible explanation. | 19:34 |
| liw | the bug was marked as medium priority by colin king, so I should perhaps ask him why | 19:35 |
| infinity | Anyhow, from what I can tell with some basic research and a bit of futzing in the code, I think the error message (for us, anyway) is entirely harmless. Just a bit scary. | 19:35 |
| smb_tp | infinity, Well the message is just plain "Cannot find map file" and then "Loaded x symbols from y modules". Not someting that let me panic | 19:35 |
| infinity | smb_tp: "Cannot find" on a file that clearly exists is cause for panic for a lot of people. :) | 19:35 |
| infinity | smb_tp: "Not loading, because of $reason" is a bit friendlier. | 19:36 |
| infinity | (The number of people METOOing the bug sort of backs up my assertion) | 19:36 |
| liw | (the real fix would might be to switch to a syslogd written by people who know C I/O) | 19:36 |
| infinity | liw: Our klogd works well enough. *shrug* | 19:37 |
| smb_tp | infinity, Agreed, it is slightly misleading | 19:37 |
| infinity | smb_tp: No one likes the second line in their boot sequence to be "I can't find ur filez noob" | 19:38 |
| liw | anyway, I'm done for today, thanks for you help with this | 19:38 |
| smb_tp | infinity, We could suggest "Confused by the contents of the file" | 19:39 |
| infinity | smb_tp: Well, I'm curious if the Version_* symbol goes away only on KALLSYMS builds, or if it's gone completely. | 19:41 |
| infinity | smb_tp: If it's gone completely, then we do have a real bug here, whether in the upstream kernel or in our klogd, where things will be suboptimal for users building their own kernels. | 19:41 |
| smb_tp | infinity, Yeah I am trying to find out for curiosity. Somehow it is not quickly grepable | 19:41 |
| infinity | smb_tp: If it's only gone on KALLSYMS builds, I call it a non-bug. | 19:41 |
| infinity | (Though the error message going away or being re-written would be swell) | 19:42 |
| infinity | liw: I tossed a pithy followup on the bug with very little technical explanation, because I didn't feel like typing. :P | 19:42 |
| infinity | liw: If you want more info there, there's plenty of backscroll here to cut and paste. :) | 19:43 |
| smb_tp | I would very much suspect if cking put it as medium, then its just a nuisance and probably time was lacking to bother | 19:44 |
| infinity | smb_tp: On the flipside, this could be seen as an accidental optimization. If we have symbol lookups built into the kernel, it's a terrible waste to have them also loaded into klogd's (probably non-pageable) memory. | 19:46 |
| smb_tp | infinity, It makes much sense. Why have that twice. Maybe just an oversight to _not_ display the message. | 19:48 |
| === zul_ is now known as zul | ||
| smb_tp | infinity, hah, yeah... | 19:51 |
| smb_tp | #ifndef CONFIG_KALLSYMS | 19:51 |
| smb_tp | #define version(a) Version_ ## a | 19:51 |
| smb_tp | in init/version.c | 19:52 |
| infinity | smb_tp: Perfect, that's what I was hoping for. | 19:52 |
| * infinity follows up to the bug again. | 19:52 | |
| smb_tp | commit 197dcffc8ba0ea943fee86e28e99cd9575799772 | 19:55 |
| smb_tp | init/version.c: define version_string only if CONFIG_KALLSYMS is not defined | 19:55 |
| infinity | smb_tp: Thanks for the backtracking. I've updated the bug to confirm that it's harmless, and to suggest making klogd's error message disappear or be made friendlier. | 19:56 |
| smb_tp | infinity, Ok, cool. | 19:56 |
| === emgent_ is now known as emgent | ||
| === bradf is now known as fdarb | ||
| rtg | apw: kirkland says he is stable now without the i945 patch. | 23:38 |
| apw | yes he said that to me too | 23:38 |
| rtg | apw: are you doing a different patch for it? | 23:39 |
| apw | the patch cannot be the trigger for pgraner's issue as it wasn't in .38 | 23:39 |
| apw | and the reports of the compiz issues explicitly were seen on .38 | 23:39 |
| apw | bug 356951 | 23:40 |
| ubot3 | Malone bug 356951 in compiz "Compiz sometimes hangs the machine" [High,Confirmed] https://launchpad.net/bugs/356951 | 23:40 |
| apw | we have no clue as to cause of his issue at this time | 23:40 |
| rtg | apw: hmm, so you're thinking that the i945 patch had nothing to do with kirkland's stability? | 23:42 |
| apw | sorry ... i am confusing you with use of him | 23:42 |
| apw | kirkland was ok on .38 and ok with 41 with the revert,. this is consistant with it being the BCHBAR patch as it was .39 material | 23:43 |
| apw | its not consistant with pgraner's issue as that is seen in .38 which does not have it | 23:44 |
| apw | (it == the patch) | 23:44 |
| rickspencer3 | apw: could that not mean (as bryce points out to me) that pgraner suffers from yet another issue? | 23:44 |
| rtg | apw: so, you're OK with reverting the BCHBAR patch? | 23:45 |
| apw | right, that is what i was trying and failing to communicate, that pgraner has a different issue | 23:45 |
| apw | i think kirkland is sufficient reason to be suspicious of the patch and revert it regardless | 23:45 |
| rtg | apw: got it. will do. | 23:46 |
| apw | rtg ack | 23:46 |
| bryce | rtg, apw: if you have any other questions on that patch, jbarnes has popped in here | 23:50 |
| rtg | bryce, jbarnes: Its been shown to be the culprit for hard lockups on kirkland's laptop (which I think is i945). | 23:52 |
| jbarnes | rtg: at boot or during use? | 23:52 |
| jbarnes | s/boot/i915 load/ | 23:52 |
| rtg | apw built a test kernel with only the BCHBAR patch reverted. it locks fairly soon after GDM starts, certainly within a few minutes. | 23:52 |
| jbarnes | MCHBAR I hope? | 23:53 |
| apw | yep | 23:53 |
| rtg | jbarnes: I think so, but he's busy at this conference using his laptop, so its hard to get much access to it. | 23:53 |
| apw | we are separately suffering a compix triggered machine hang on a number of systems | 23:54 |
| jbarnes | hm | 23:54 |
| apw | yep saw it with my own eyes, hard locks, compiz off | 23:54 |
| jbarnes | the MCHBAR patch will allow for tiled rendering on more machines... | 23:54 |
| apw | revert the patch and goodness ensues | 23:54 |
| jbarnes | so there may be a more generic tiling related problem | 23:54 |
| apw | and blow up machines | 23:54 |
| apw | :) | 23:54 |
| apw | jbarnes, does sound feasable | 23:55 |
| jbarnes | that could be confirmed by running with the patch but adding option "tiling" "false" to xorg.conf's intel driver section | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!