Summary: | [2.6.21 regression] gettimeofday returning 1000000 in tv_usec on core2duo | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Santiago Gala <sgala> |
Component: | Current packages | Assignee: | Daniel Drake (RETIRED) <dsd> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | kernel |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://bugzilla.kernel.org/show_bug.cgi?id=8479 | ||
Whiteboard: | linux-2.6.21-regression | ||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 176188 |
Description
Santiago Gala
2007-05-10 06:20:35 UTC
I know. I get this too. Here's what upstream had to say about it: This is a known problem. It only happens when using Gecko for rendering and it doesn't happen with every Gecko version. I currently cannot reproduce it, but had the same problem some months ago and even a while before. The problem is that I do not how to realize safe GDK thread locking with Gecko which does not support the GDK locking style, at least until now I found no way to use it without dead locking right after startup. And without correct locking I assume it is just a timing propability that the program locks up. Won't fix, as I have no clue how. This is so bad that I'm considering stopping using liferea. The extra problem here is that I can't use gtkhtml, even if the build does not show the USE flag in parenthesis, inside it: !amd64? ( !xulrunner? ( !firefox? ( !seamonkey? ( =gnome-extra/gtkhtml-2* ) ) ) ) !amd64? ( gtkhtml? ( =gnome-extra/gtkhtml-2* ) ) so amd64 can't try gtkhtml :( Nope. gtkhtml isn't supported (and often crashes) on amd64. Sorry. You can try firefox or seamonkey; I've only seen the problem on the newest xulrunner. I've tracked this down to a 2.6.21 kernel bug on core2duos, possibly on the T7200 (since all known instances of this bug are on T7200's) The best solution at this point is to downgrade to 2.6.20, since this will undoubtedly cause other problems than liferea hanging. I will commit a workaround to liferea tomorrow, however, if it survives the night intact. I'm changing this to the correct kernel bug, and assigning to kernel, so it can block 2.6.21 going stable on amd64 until the upstream patch goes in. Please post the following from the system this is happening on: * dmesg * lspci * lsmod * kernel config Thanks wouldn't it make sense to push the micropatch: --- arch/x86_64/kernel/vsyscall.c +++ arch/x86_64/kernel/vsyscall.c @@ -132,7 +132,7 @@ static __always_inline void do_vgettimeo /* convert to usecs and add to timespec: */ tv->tv_usec += nsec_delta / NSEC_PER_USEC; - while (tv->tv_usec > USEC_PER_SEC) { + while (tv->tv_usec >= USEC_PER_SEC) { tv->tv_sec += 1; tv->tv_usec -= USEC_PER_SEC; } in http://bugzilla.kernel.org/show_bug.cgi?id=8479 , or the full patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;f=arch/x86_64/kernel/vsyscall.c;h=dc32cef961950915fbaa185e36ab802d5f7cea3b;hp=ba330f87067996a17495f7d03466d646c718b52c;hb=c8118c6c07f2edfd697aaa0b93e08c3b65a5a675;hpb=272a3713bb9e302e0455c894c41180a482d2c8a3 into 2.6.21 patchset for amd64? Just FYI Indeed, will do that. Thanks. Fixed in gentoo-sources-2.6.21-r1 (genpatches-2.6.21-2) FYI, it is already patches in gentoo-sources-2.6.21-r1 |