| === zequence_ is now known as zequence | ||
| === psivaa is now known as psivaa-bbib | ||
| === psivaa-bbib is now known as psivaa | ||
| === lool- is now known as lool | ||
| === stgraber_ is now known as stgraber | ||
| Joe_CoT | So unless I'm missing something, the TSC Zen bug that was fixed in 12.04 got reintroduced somehow in 14.04. I'm having dmesg time jumps of 7000000 seconds. How would I go about getting that fixed? | 20:53 |
|---|---|---|
| Joe_CoT | Forum post here: http://ubuntuforums.org/showthread.php?t=2236742 | 20:53 |
| bjf | Joe_CoT, please file a bug on the problem and then come back here and tell us what the bug# is. if it asks you for logs, just ignore it. | 21:00 |
| Joe_CoT | So my question is that it looks like it falls under this bug, which is "fix released": https://bugs.launchpad.net/ubuntu/+source/linux/+bug/727459 Do I open a new one? | 21:01 |
| ubot5 | Launchpad bug 727459 in linux (Ubuntu Lucid) "TSC is not reliable under Xen on some Intel CPUs" [Medium,Triaged] | 21:01 |
| bjf | Joe_CoT, it *does* seem like the same bug | 21:02 |
| Joe_CoT | yeah. So I'm not sure if that bug should be reopened somehow, or if I should post a new one, or what. Or how I'd check whether the code change is already in this version of the kernel | 21:03 |
| bjf | Joe_CoT, let me "reopen" it ... one sec. | 21:04 |
| bjf | Joe_CoT, i've added a "trusty" task for it. can you please add a comment to the bug that indicates the problem is back? | 21:05 |
| bjf | Joe_CoT, subscribe to it and if you get asked to test a kernel with a possible fix, try to test. that helps a lot. | 21:06 |
| bjf | smb, bug 727459 | 21:06 |
| ubot5 | bug 727459 in linux (Ubuntu Lucid) "TSC is not reliable under Xen on some Intel CPUs" [Medium,Triaged] https://launchpad.net/bugs/727459 | 21:06 |
| Joe_CoT | Thanks very much for the help! | 21:09 |
| bjf | Joe_CoT, np | 21:09 |
| bjf | Joe_CoT, we'll need to know what version of trusty you are running. a full dmesg might be nice, otherwise a uname -a | 21:11 |
| Joe_CoT | OK, I've attached the full dmesg | 21:13 |
| bjf | Joe_CoT, that kernel is an older one. can you try a newer kernel? | 21:15 |
| bjf | Joe_CoT, 3.13.0-32.57 is in -updates | 21:15 |
| Joe_CoT | heh. The problem is that if I restart the server, it'll be a crap shoot as to whether it happens again | 21:19 |
| Joe_CoT | I'll try it and post if it happens. If it doesn't I guess I'll rebase my AMI to the new kernel so I'll see it next time | 21:19 |
| bjf | Joe_CoT, well, there's a chance that it's been fixed. if you don't test, we'll never know. | 21:20 |
| Joe_CoT | well hopefully it happens immediately again. If not it might be a while before I know if it worked | 21:20 |
| bjf | ack | 21:21 |
| bjf | "hopefully" it never happens again :-) | 21:21 |
| Joe_CoT | bjf, happens on the new kernel too. Updated | 21:35 |
| bjf | Joe_CoT, cool, thanks for the test | 21:35 |
| Joe_CoT | This also brings up another fun topic: the reason I was running the old kernel is that, apparently in 14.04, it asks you if you want to use the package maintainers menu.lst. The difference between the local one and the package maintainer's one? Loading the kernel that just got installed. So if you choose the default, keep the current installed one, the new kernels are just never loaded. | 21:49 |
| bjf | Joe_CoT, that seems non-intuitive | 21:50 |
| Joe_CoT | I'm aware. So I haven't been loading kernel security updates for a while it seems | 21:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!