Bug#691576: GDB still broken with 3.11.10-1
2014/1/12 Ben Hutchings b...@decadent.org.uk: If you have space to install wheezy on a separate partition, please can you try that. (Of course, that crash ought to be fixed in 3.2.y. But I don't know that anyone will have the time and knowledge to do so. And it's not part of this bug.) No more empty partition, so I managed to back up all my data and reinstall a fresh Wheezy 7.0.3 from the netinst CD. The issue with elilo that I reported back in May is still there [1]. Performed all the updates and install your -O1 kernel. Bang! Exact same crash as reported in [2]. Émeric [1] https://lists.debian.org/debian-68k/2013/05/msg00065.html === BTW, why is it archived on debian-68k? [2] https://lists.debian.org/debian-ia64/2014/01/msg9.html -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691576: GDB still broken with 3.11.10-1
2014/1/7 Ben Hutchings b...@decadent.org.uk: On Mon, 2014-01-06 at 10:15 +0100, Émeric MASCHINO wrote: I don't understand that - I still have 3.2 installed on this unstable (i386) system and can still boot it. How does it go wrong? It seems to crash with something wrong with systemd. You're getting in loop a callstack similar to the one starting at 32.334142, every ~28 seconds. And you can wait forever, never reaching login: Uncompressing Linux... done Loading file \EFI\debian\initrd.img.old...done [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.2.0-4-mckinley (debian-ker...@lists.debian.org) ( gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.51-1a~test [0.00] EFI v1.10 by HP: SALsystab=0x3fb38000 ACPI 2.0=0x3fb2e000 SMBIOS= 0x3fb3a000 HCDP=0x3fb2c000 [0.00] booting generic kernel on platform hpzx1 [0.00] PCDP: v0 at 0x3fb2c000 [0.00] Explicit console=; ignoring PCDP [0.00] ACPI: RSDP 3fb2e000 00028 (v02 HP) [0.00] ACPI: XSDT 3fb2e02c 00094 (v01 HP zx6000 HP ) [0.00] ACPI: FACP 3fb36800 000F4 (v03 HP zx6000 HP ) [0.00] ACPI Warning: 32/64X length mismatch in Gpe0Block: 32/16 (2011062 3/tbfadt-529) [0.00] ACPI Warning: 32/64X length mismatch in Gpe1Block: 32/16 (2011062 3/tbfadt-529) [0.00] ACPI: DSDT 3fb2e0e0 05781 (v01 HP zx6000 0007 I NTL 02012044) [0.00] ACPI: FACS 3fb368f8 00040 [0.00] ACPI: SPCR 3fb36938 00050 (v01 HP zx6000 HP ) [0.00] ACPI: DBGP 3fb36988 00034 (v01 HP zx6000 HP ) [0.00] ACPI: APIC 3fb36a48 000B0 (v01 HP zx6000 HP ) [0.00] ACPI: SPMI 3fb369c0 00050 (v04 HP zx6000 HP ) [0.00] ACPI: CPEP 3fb36a10 00034 (v01 HP zx6000 HP ) [0.00] ACPI: SSDT 3fb33870 001D6 (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb33a50 00342 (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb33da0 00A16 (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb347c0 00A16 (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb351e0 00A16 (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb35c00 00A16 (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb36620 000EB (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb36710 000EF (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: Local APIC address c000fee0 [0.00] 2 CPUs available, 2 CPUs total [0.00] SMP: Allowing 2 CPUs, 0 hotplug CPUs [0.00] Initial ramdisk at: 0xe040fdd01000 (19443165 bytes) [0.00] SAL 3.1: HP version 2.31 [0.00] SAL Platform features: None [0.00] SAL: AP wakeup using external interrupt vector 0xff [0.00] MCA related initialization done [0.00] Virtual mem_map starts at 0xa0007fffc720 [0.00] Zone PFN ranges: [0.00] DMA 0x0400 - 0x0004 [0.00] Normal 0x0004 - 0x0104 [0.00] Movable zone start PFN for each node [0.00] early_node_map[6] active PFN ranges [0.00] 0: 0x0400 - 0xfd79 [0.00] 0: 0xfec0 - 0xfecb [0.00] 0: 0x0004 - 0x0017 [0.00] 0: 0x0101 - 0x0103ff5a [0.00] 0: 0x0103ff6a - 0x0103ff84 [0.00] 0: 0x0103ffa0 - 0x0103fff0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pag es: 1512906 [0.00] Policy zone: Normal [0.00] Kernel command line: BOOT_IMAGE=scsi1:/EFI/debian/vmlinuz.old roo t=/dev/sdb2 console=ttyS0,9600 ro [0.00] PID hash table entries: 4096 (order: 1, 32768 bytes) [0.00] Memory: 25010192k/25105424k available (8557k code, 128096k reserv ed, 4496k data, 1088k init) [0.00] Hierarchical RCU implementation. [0.00] CONFIG_RCU_FANOUT set to non-default value of 32 [0.00] NR_IRQS:1024 [0.00] ACPI: Local APIC address c000fee0 [0.00] GSI 36 (level, low) - CPU 0 (0x) vector 49 [0.00] Console: colour VGA+ 80x25 [0.004000] Calibrating delay loop... 2246.65 BogoMIPS (lpj=4493312) [0.032028] pid_max: default: 32768 minimum: 301 [0.032211] Security Framework initialized [0.032223] AppArmor: AppArmor disabled by boot time parameter [0.033832] Dentry cache hash table entries: 4194304 (order: 11, 33554432 byt es) [0.065085] Inode-cache hash table entries: 2097152 (order: 10, 16777216 byte s) [0.080407] Mount-cache hash table entries: 1024
Bug#691576: GDB still broken with 3.11.10-1
2014/1/12 Ben Hutchings b...@decadent.org.uk: So this is a crash, not an incompatibility with the newer systemd. [...] Can you test the 3.2 kernel with sysvinit, in case this is a bug that's specifically provoked by systemd? That's why I was saying too old for my current Debian install on Jan 6th. Since I'm running GNOME 3.8, do you think I can safely reinstall and reboot with sysvinit or everything will be badly broken? Émeric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691576: GDB still broken with 3.11.10-1
2014/1/12 Ben Hutchings b...@decadent.org.uk: You can have sysvinit and systemd installed in parallel and then use the 'init' kernel parameter to switch between them. Only systemd-sysv conflicts/replaces sysvinit. So, I've reinstalled sysvinit and sysvinit-core that purged systemd-sysv. I can't however remove systemd itself as it's required by numerous GNOME packages. I've rebooted my system and even reinstalled your -O1 kernel in order to be sure that initrd is regenerated. Still the same however! How is it that systemd-udevd still shows up? Emeric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691576: GDB still broken with 3.11.10-1
2014/1/12 Ben Hutchings b...@decadent.org.uk: Sorry, I'm being silly. udev is built as part of systemd now, so this is independent of whether you use systemd as init. And systemd doesn't currently run as init in the initramfs. Uh, OK. How can I help further? Emeric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691576: GDB still broken with 3.11.10-1
Hi, And happy new year! 2013/12/20 Ben Hutchings b...@decadent.org.uk: I actually tried building the kernel like that, so you could try the packages in: http://people.debian.org/~benh/packages/wheezy-ia64-kernel-O1/ Was your O1-compiled kernel working fine? I have no idea as no-one has reported their results yet. It seems that optimization settings have impact on this problem. Ben, I couldn't install your 3.2 kernel version (too old for my current Debian install). However, I've recompiled with -O1 a -O2 non-working kernel configuration on my Gentoo install. No problem with -O1 :-) Keep in mind that this is just an observation on a single kernel version/flavour at the moment. Future will tell us if this problem really comes up with optimization settings. Émeric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691576: GDB still broken with 3.11.10-1
2013/12/12 Ben Hutchings b...@decadent.org.uk: So far as I know, there is no longer any commercial development of Linux on Itanium. Some old 'enterprise' distributions might continue to be supported for a few years but mainline isn't supported. It seems that Intel must provide hp with Itanium CPUs till 2017 [1][2]. With respect to this GDB problem, but also people having problem booting Wheezy on some systems, does it mean that nobody at Intel ensure that Linux still works fine with actual (and upcoming?) Itanium CPUs? Well, since hp is the major customer for Itanium CPUs, it's entirely plausible after all that hp focuses on hp-ux and thus Intel doesn't care about Linux on ia64. I heard from Will Deacon that gcc's code generation for ia64 has regressed in 4.6 or earlier and this may be responsible for some reported kernel bugs. He also though that reducing the optimisation level could help. I actually tried building the kernel like that, so you could try the packages in: http://people.debian.org/~benh/packages/wheezy-ia64-kernel-O1/ No, I didn't play with GCC optimization settings. Was your O1-compiled kernel working fine? Do you know if GCC regressions observed by Will Deacon are documented somewhere? Émeric [1] http://www.xbitlabs.com/news/cpu/display/20120201201109_HP_Paid_Intel_690_Million_to_Keep_Itanium_Alive_Court_Findings.html [2] http://www.wired.com/wiredenterprise/2012/02/hp-itanium/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691576: GDB still broken with 3.11.10-1
Ben, I was not reporting this as a reproach, but simply to track down which kernels work and which don't. From my records: - 2.6.38: KO (*) see below - 3.0.0-2: OK - 3.1.0-1: KO - 3.2.23: KO - 3.2.35-2: OK - 3.2.46-1+deb7u1: KO - 3.10.11-1: OK - 3.11.8-1: KO - 3.11.10-1: KO About upstream, I still don't understand how is it that this problem hasn't been talked about. I know I'm a bad programmer, but I would be very surprised being the only one needing GDB on ia64 ;-) I don't know if upstream people are subscribed to this list. When I asked on linux-ia64 which distro ia64 people are running [1], the only answer I got was from Raúl Porcel, the Gentoo-ia64 maintainer, nothing from Intel or hp developers. So I don't know how Linux/ia64 development is managed. Are Intel and hp people using a custom distro? Are they simply running Itanium systems? This is a legitimate question as I don't remember that they ever commented on this issue. Is it that they don't hit it? In fact, the only occurrence about this issue I can find on the linux-ia64 list is one of my remark in a post about a regression introduced with Sanitize cmpxchg_futex_value_locked API patch [2]. (*) And this was during kernel 2.6.38 development cycle! Bisecting back to such old kernel is simply impossible with today's udev and because of accept4 syscall was missing in 3.2.0-1 kernels. Also, as I reported some times ago [3], this issue is not specific to Debian kernels. In fact, a given kernel version can break GDB or not, depending upon its configuration (i.e. depending whether code is statically built or built as modules). Once again, I didn't get any comment on this, so don't know how I can help further: I'm not a kernel developer and have no knowledge of ia64 internals, except what I've read in ia-64 linux kernel book by David Mosberger and Stéphane Eranian, with a lot of things far behind my understanding. And even if I can go back as old as kernel 2.6.38, how to be sure that everything was definitely working fine then or just being lucky because of a working kernel configuration? Émeric [1] http://marc.info/?l=linux-ia64m=134858659916369w=2 [2] http://marc.info/?l=linux-ia64m=133124040906499w=2 [3] http://lists.debian.org/debian-ia64/2013/09/msg00024.html 2013/12/11 Ben Hutchings b...@decadent.org.uk: On Tue, Dec 10, 2013 at 11:36:37PM +0100, Émeric MASCHINO wrote: FYI, linux-image-3.11-2-mckinley 3.11.10-1 in today's Jessie updates didn't change anything w.r.t. gdb problem. Of course it didn't. If you want ia64 fixed then you'll have to talk to upstream or fix it yourself. Ben. -- Ben Hutchings If God had intended Man to program, we'd have been born with serial I/O ports. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691576: GDB still broken with 3.11.10-1
FYI, linux-image-3.11-2-mckinley 3.11.10-1 in today's Jessie updates didn't change anything w.r.t. gdb problem. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691576: linux-image-mckinley 3.10+52 is fine again with gdb
FYI, linux-image-3.10-3-mckinley 3.10.11-1 in today's Jessie updates brought back gdb to life. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719802: ia64, Iceweasel-17, JS needs ptrs have their high 17 bits cleared
Thanks Stephan, I'll test your patches. And I bet that the same will have to be done for Firefox ESR 21? BTW, I don't understand how upstream code is versioned. Shouldn't your original patches have been ported to the new JS engine by upstream when they released Firefox ESR 10 versions? Otherwise, what would prevent such breakages in the future with ESR 28, 35, ...? And the same for Webkit? I've reoppened bug 642750, as Epiphany status is as bad as Iceweasel ESR 17 since they switched from Webkit 1.8.1 to 2.0.4. Emeric 2013/8/28 Stephan Schreiber i...@fs-driver.org: retitle 719802 ia64, Iceweasel-17, JS needs ptrs have their high 17 bits cleared reassign 719802 src:iceweasel severity 719802 grave tags 719802 + patch thanks ia64. I experienced it, too. An assertion GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed Iceweasel 17esr crashed immediately before it shows its window on ia64. Furthermore the testsuite sometimes crashed when I built the unpatched iceweasel 17.0.8esr-2 on ia64. The failing assertion is *not* related with the crash. I didn't care about it. The reason for the crash is a known one: The Mozilla JS engine needs pointers have their high 17 bits cleared because it would break a variant data type which the engine uses. The patch doesn't fix the failing assertion. It will still occur, but the crash is gone. The patch is also important for the libmozjs17d package which will be used by gnome-shell soon. The patch is similar to some bugfixes of earlier versions: bug#696041 ia64 (Itanium) Mozilla JS engine needs pointers have their high 17 bits cleared bug#659186 gnome-shell: Segmentation fault in libmozjs185.so.1.0 at startup Noam Postavsky wrote: I'm having the same symptoms (same assertion failure and crash at startup) on amd64. The amd64 arch isn't affected by the ia64 crash which this patch addresses, believe me ;-) I suggest filing a separate bug report for the crash on amd64. Cheers Stephan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642750: epiphany-browser once again unusable on ia64
Hi, With the switch from WebKit 1.8.1 to 2.0.4, instability is back on IA-64: Epiphany simply can't open any URL without crashing (cf. the attached gdb output when trying to go to http://www.gnome.org). Émeric Starting program: /usr/bin/epiphany-browser warning: Could not load shared library symbols for linux-gate.so.1. Do you need set solib-search-path or set sysroot? [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/ia64-linux-gnu/libthread_db.so.1. [New Thread 0x2ade2f10 (LWP 2116)] [New Thread 0x2ba02f10 (LWP 2117)] [New Thread 0x2000147fef10 (LWP 2120)] [New Thread 0x200015f02f10 (LWP 2121)] [New Thread 0x200016906f10 (LWP 2125)] [Thread 0x200015f02f10 (LWP 2121) exited] [New Thread 0x200015f02f10 (LWP 2127)] [New Thread 0x20002c2fef10 (LWP 2128)] [New Thread 0x20002cefef10 (LWP 2129)] [New Thread 0x20002d6fef10 (LWP 2130)] [New Thread 0x20002defef10 (LWP 2131)] [New Thread 0x20002e6fef10 (LWP 2132)] [New Thread 0x20002eefef10 (LWP 2133)] Program received signal SIGSEGV, Segmentation fault. 0x21223121 in WebCore::getCachedDOMStructure(WebCore::JSDOMGlobalObject*, JSC::ClassInfo const*) () from /usr/lib/libwebkitgtk-3.0.so.0 #0 0x21223121 in WebCore::getCachedDOMStructure(WebCore::JSDOMGlobalObject*, JSC::ClassInfo const*) () from /usr/lib/libwebkitgtk-3.0.so.0 #1 0x2124fd80 in WebCore::toJS(JSC::ExecState*, WebCore::JSDOMGlobalObject*, WebCore::Document*) () from /usr/lib/libwebkitgtk-3.0.so.0 #2 0x212c3470 in WebCore::createWrapper(JSC::ExecState*, WebCore::JSDOMGlobalObject*, WebCore::Node*) () from /usr/lib/libwebkitgtk-3.0.so.0 #3 0x21238b10 in WebCore::JSDOMWindowBase::updateDocument() () from /usr/lib/libwebkitgtk-3.0.so.0 #4 0x21315d70 in WebCore::ScriptController::initScript(WebCore::DOMWrapperWorld*) () from /usr/lib/libwebkitgtk-3.0.so.0 #5 0x21316c50 in WebCore::ScriptController::evaluateInWorld(WebCore::ScriptSourceCode const, WebCore::DOMWrapperWorld*) () from /usr/lib/libwebkitgtk-3.0.so.0 #6 0x21317440 in WebCore::ScriptController::evaluate(WebCore::ScriptSourceCode const) () from /usr/lib/libwebkitgtk-3.0.so.0 #7 0x2186c270 in WebCore::ScriptElement::executeScript(WebCore::ScriptSourceCode const) () from /usr/lib/libwebkitgtk-3.0.so.0 #8 0x21d3c440 in WebCore::HTMLScriptRunner::executePendingScriptAndDispatchEvent(WebCore::PendingScript) () from /usr/lib/libwebkitgtk-3.0.so.0 #9 0x21d3cf30 in WebCore::HTMLScriptRunner::executeParsingBlockingScript() () from /usr/lib/libwebkitgtk-3.0.so.0 #10 0x21d3d870 in WebCore::HTMLScriptRunner::executeParsingBlockingScripts() () from /usr/lib/libwebkitgtk-3.0.so.0 #11 0x21d3d8f0 in WebCore::HTMLScriptRunner::executeScriptsWaitingForStylesheets() () from /usr/lib/libwebkitgtk-3.0.so.0 #12 0x21d05cf0 in WebCore::HTMLDocumentParser::executeScriptsWaitingForStylesheets() () from /usr/lib/libwebkitgtk-3.0.so.0 #13 0x217340a0 in WebCore::Document::didRemoveAllPendingStylesheet() () from /usr/lib/libwebkitgtk-3.0.so.0 #14 0x217749f0 in WebCore::DocumentStyleSheetCollection::removePendingSheet(WebCore::DocumentStyleSheetCollection::RemovePendingSheetNotificationType) () from /usr/lib/libwebkitgtk-3.0.so.0 #15 0x21c08350 in WebCore::HTMLLinkElement::removePendingSheet(WebCore::HTMLLinkElement::RemovePendingSheetNotificationType) () from /usr/lib/libwebkitgtk-3.0.so.0 #16 0x21c08430 in WebCore::HTMLLinkElement::sheetLoaded() () from /usr/lib/libwebkitgtk-3.0.so.0 #17 0x216a2d20 in WebCore::StyleSheetContents::checkLoaded() () from /usr/lib/libwebkitgtk-3.0.so.0 #18 0x216a2b00 in WebCore::StyleSheetContents::checkLoaded() () from /usr/lib/libwebkitgtk-3.0.so.0 #19 0x21697f70 in WebCore::StyleRuleImport::setCSSStyleSheet(WTF::String const, WebCore::KURL const, WTF::String const, WebCore::CachedCSSStyleSheet const*) () from /usr/lib/libwebkitgtk-3.0.so.0 #20 0x21699ec0 in WebCore::StyleRuleImport::ImportedStyleSheetClient::setCSSStyleSheet(WTF::String const, WebCore::KURL const, WTF::String const, WebCore::CachedCSSStyleSheet const*) () from /usr/lib/libwebkitgtk-3.0.so.0 #21 0x220a2190 in WebCore::CachedCSSStyleSheet::checkNotify() () from /usr/lib/libwebkitgtk-3.0.so.0 #22 0x220a19d0 in WebCore::CachedCSSStyleSheet::data(WTF::PassRefPtrWebCore::ResourceBuffer, bool) () from /usr/lib/libwebkitgtk-3.0.so.0 #23 0x221f1d00 in WebCore::SubresourceLoader::didFinishLoading(double) () from /usr/lib/libwebkitgtk-3.0.so.0 #24 0x221d4780 in WebCore::ResourceLoader::didFinishLoading(WebCore::ResourceHandle*, double) () from /usr/lib/libwebkitgtk-3.0.so.0 #25 0x2382e930 in WebCore::readCallback(_GObject*, _GAsyncResult*, void*) () from /usr/lib/libwebkitgtk-3.0.so.0 #26 0x25b1f320 in
Bug#642750: epiphany-browser: *HIGHLY* unstable on ia64 (IA-64/IPF/Itanium) platform
Hi and happy new year, I've tested latest patchset from Stephan. Epiphany runs as great as with the v2 patchset. I'm however still getting the curious Google homepage crash I was talking about previously. Uninstalling gnash didn't help. But overall, Stephan work is a _huge_ improvement w.r.t. what we had before! Kudos to him. Best regards, Emeric 2013/1/2 Stephan Schreiber i...@fs-driver.org: I filed bug#697172 for yet another bug of webkit. Furthermore, bug#697173 for a bug in the epiphany-browser package. Furthermore, bug#697174 in order to enable seed on ia64. I also realized that gnash seems to crash epiphany sometimes. I browsed through the Debian bug reports and found ones which blame gnash to make the webkit based browsers unstable - epiphany-bowser on Gnome and Konqueror on KDE: bug#594822, 655839, 549309. I removed both gnash and gnash-common from my computer and realized a real improvement of epiphany's behaviour. But I still experienced some trouble, for example, a reproducable hang-up and a crash a few seconds subsequently: Enter www.kununu.de; enter a company name in the top right search edit box; enter; click on a company's name - hang-up, crash. I tried Fedora 17 i386 on another box (epiphany-browser 3.4.3; webkit 1.8.3; gnash isn't installed): same behaviour. It isn't an ia64 specific bug. I think epiphany-browser/webkit with all patches runs on ia64 as stable as on x86; this is the best we can do at the moment. A summary of the patches we had so far: webkit, this bug report 01-ia64-wide-ptr.patch 02-ia64-use-system-malloc.patch webkit, bug#694971 large-mem-page.patch webkit, bug#697172 thread-safe-icon-db.patch seed, bug#582774 seed no longer FTBFS without any change epiphany-browser, bug#697173 history-thread-startup-race.patch epiphany-browser, bug#697174 enabling seed in debian/rules If you want to test it, you can download the built debs: http://www.fs-driver.org/debian-ia64/webkitgtk-debs-v3.tar http://www.fs-driver.org/debian-ia64/seed-debs.tar http://www.fs-driver.org/debian-ia64/epiphany-debs.tar Remember to remove both gnash and gnash-common before you test it. Stephan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692053: [ia64] Iceweasel 10.0 (and above?) randomly stops responding, eating 100% CPU
Hi, I've applied Stephan patches and recompiled Iceweasel. I used it for one week now without any problem. I even ran WebGL conformance test suite successfully whereas vanilla Iceweasel isn't able to complete it after a few tests. Notice however that, when I say successfully, I mean the process of running the tests. This doesn't mean that all tests passed successfully, but this is not related to this bug report ;-) Thank you again Stephan for your hard work. Emeric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642750: [PATCH] epiphany-browser: *HIGHLY* unstable on ia64, (IA-64/IPF/Itanium) platform
Hi Stephan,
I used your patched packages the passed week for my homeworks.
Stability is far better than the first patchset. With the notable
exception of the Google homepage. I don't know what's going wrong and
if other URLs are also affected. Let me explain.
Opening Epiphany with a blank page as startup page, typing
www.google.com in the bar address and clicking on Enter briefly goes
to the Google homepage and Epiphany immediately crashes. This is not a
history problem as going to the e.g. Debian homepage from the blank
page runs as expected. Then, from the Debian homepage, if you try to
go to the Google homepage, Epiphany crashes.
Now, the funny thing: from the blank page, if you visit the GMail
homepage first, and then the Google homepage, no problem! You can even
go back to the blank page and then visit the Google homepage without
crashing Epiphany. So the position in the history doesn't matter. I
don't know what the GMail homepage triggers that makes the Google
homepage work, but here is it. Just a remark: you don't have to visit
the GMail homepage right before the Google homepage. You can visit
other homepages in between. It's just that if you didn't visit the
GMail homepage before going to the Google homepage, Epiphany will
crash.
I know it's not a fantastic information, but that's the only
reproducible scenario I have that makes Epiphany crashes with your
updated packages.
Let me know if additional tests are welcomed.
Émeric
2012/12/7 Stephan Schreiber i...@fs-driver.org:
Émeric Maschino wrote:
Indeed, even with your updated packages, Epiphany still crashes with
the scenario I described in this bug report
I looked for anything that is different on a release build and on a debug
build. It turned out that a lot of code related to the memory heap is
different in Source/JavaScriptCore/wtf/FastMalloc.cpp:
#if !(defined(USE_SYSTEM_MALLOC) USE_SYSTEM_MALLOC) defined(NDEBUG)
#define FORCE_SYSTEM_MALLOC 0
#else
#define FORCE_SYSTEM_MALLOC 1
#endif
(Consider NDEBUG.)
Webkit doesn't use its own heap implementation in FastMalloc.cpp on the
debug build! When someone builds the release build all the buggy code runs
and will make trouble.
This was done to make debugging much easier :-). (Greetings from Google's
sadists club.)
I didn't try to find all bugs in the fast malloc implementation. One thing I
noticed which could break it on ia64 but works on x86-64 is the following in
Source/JavaScriptCore/wtf/FastMalloc.cpp:1375:
// Return 0 if we have no information, or else the correct sizeclass for
p.
// Reads and writes to pagemap_cache_ do not require locking.
// The entries are 64 bits on 64-bit hardware and 16 bits on
// 32-bit hardware, and we don't mind raciness as long as each read of
// an entry yields a valid entry, not a partially updated entry.
size_t GetSizeClassIfCached(PageID p) const {
return pagemap_cache_.GetOrDefault(p, 0);
}
void CacheSizeClass(PageID p, size_t cl) const { pagemap_cache_.Put(p,
cl); }
When different processor cores access one memory location - one processor at
first, the second one at next - the processor cores excange the data through
their caches as needed with their bus protocol automatically on x86 and
x86-64.
But on ia64 caches are not coherent automatically, the caches are flushed
using memory barriers (some special machine instructions).
When you use some dispatcher objects, for example, a mutex with the
following pattern
- acquire the dispatcher object
- read/write to the data location which are guarded by the dispatcher
object,
- release the dispatcher object
you don't need to think on the cache coherency and memory barriers. The
implementation of the dispatcher object does the memory barriers correctly
for you.
When you start to do something own what has multiple threads but doesn't use
any dispatcher object, you have to think on memory barriers. Ia64 isn't the
only arch that requires this.
One approach would be building-in the needed memory barrier in
FastMalloc.cpp. This would mean adding memory barrier definitions for a lot
of architectures. You can take a look at the hw/xfree86/common/compiler.h
file of the xserver-xorg-core package in order to get an idea what it would
mean.
So the second approach: We do no longer use the fast malloc implementation
on ia64 as it is already done on Blackberry OS and on the Qt port of webkit
on any OS other than UNIX.
An appropriate modification can be useful as well on other archs that
require memory barriers, for example, alpha, powerpc.
So here is a new set of patches:
01-ia64-wide-ptr.patch at first,
02-ia64-use-system-malloc.patch at next.
The patches are for the most recent libwebkitgtk-3.0-0 package of Wheezy.
The patches don't change anything on archs other than ia64.
The packages which were built with the patch of this bug report and the one
of bug#694971 are here; the tar contains all debs which
Bug#642750: [PATCH] epiphany-browser: *HIGHLY* unstable on ia64 (IA-64/IPF/Itanium) platform
Thanks Stephan for your hard work.
I just tested Epiphany with the updated packages that you provided in
[1]. Are they self-contained or is yet another updated package
missing?
Indeed, even with your updated packages, Epiphany still crashes with
the scenario I described in this bug report, albeit you don't have to
click again on Debian URL to make it crash. Simply going back to the
Google results page and waiting a little bit is sufficient to trigger
the crash.
And unfortunately, trying to get an informative stacktrace in gdb, I'm
now hitting the SIGTRAP issue [2] :-(
Émeric
[1] http://www.fs-driver.org/debian-ia64/webkitgtk-debs.tar
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691576
2012/12/2 Stephan Schreiber i...@fs-driver.org:
severity 642750 grave
tags 642750 + patch
block 582774 by 642750
thanks
While working on this bug I realized that webkit has yet another bug that
prevents it from working on ia64. I filed the separate bug#694971 for that.
I built the libwebkitgtk-3.0-0 package which was configured with
--enable-debug. (Wasn't possible with the initial 4GB of memory at all.
After a memory upgrade to 16GB it took eleven-and-a-half hour on my box with
the -j2 option.)
Just starting epiphany-browser showed a first hint what is going on:
ASSERTION FAILED: isCell()
../Source/JavaScriptCore/runtime/JSValueInlineMethods.h(491) : JSC::JSCell*
JSC::JSValue::asCell() const
Webkit uses a variant data type JSValue, which it uses for anything that can
be a thing on Java script. It can contain an integer number, a float number
or a pointer to an object - this is 'cell'.
It turned out that the 'isCell()' assertion failed for a JSValue that just
has been initialized as a pointer.
The arch determines how the JSValue is defined; there are two options (yet),
one for any 32-bits arch, the other one for 64-bits archs.
You can see this in Source/JavaScriptCore/runtime/JSValue.h - JSValue
defines an embedded data type 'EncodedValueDescriptor' for that:
#if USE(JSVALUE32_64)
typedef int64_t EncodedJSValue;
#else
typedef void* EncodedJSValue;
#endif
union EncodedValueDescriptor {
int64_t asInt64;
#if USE(JSVALUE32_64)
double asDouble;
#elif USE(JSVALUE64)
JSCell* ptr;
#endif
#if CPU(BIG_ENDIAN)
struct {
int32_t tag;
int32_t payload;
} asBits;
#else
struct {
int32_t payload;
int32_t tag;
} asBits;
#endif
};
#if USE(JSVALUE32_64)
/*
* On 32-bit platforms USE(JSVALUE32_64) should be defined, and we
use a NaN-encoded
* form for immediates.
*
* The encoding makes use of unused NaN space in the IEEE754
representation. Any value
* with the top 13 bits set represents a QNaN (with the sign bit
set). QNaN values
* can encode a 51-bit payload. Hardware produced and C-library
payloads typically
* have a payload of zero. We assume that non-zero payloads are
available to encode
* pointer and integer values. Since any 64-bit bit pattern where
the top 15 bits are
* all set represents a NaN with a non-zero payload, we can use this
space in the NaN
* ranges to encode other values (however there are also other
ranges of NaN space that
* could have been selected).
*
* For JSValues that do not contain a double value, the high 32 bits
contain the tag
* values listed in the enums below, which all correspond to
NaN-space. In the case of
* cell, integer and bool values the lower 32 bits (the 'payload')
contain the pointer
* integer or boolean value; in the case of all other tags the
payload is 0.
*/
enum { Int32Tag =0x };
enum { BooleanTag = 0xfffe };
enum { NullTag = 0xfffd };
enum { UndefinedTag =0xfffc };
enum { CellTag = 0xfffb };
enum { EmptyValueTag = 0xfffa };
enum { DeletedValueTag = 0xfff9 };
enum { LowestTag = DeletedValueTag };
uint32_t tag() const;
int32_t payload() const;
#elif USE(JSVALUE64)
/*
* On 64-bit platforms USE(JSVALUE64) should be defined, and we use
a NaN-encoded
* form for immediates.
*
* The encoding makes use of unused NaN space in the IEEE754
representation. Any value
* with the top 13 bits set represents a QNaN (with the sign bit
set). QNaN values
* can encode a 51-bit payload. Hardware produced and C-library
payloads typically
* have a payload of zero. We assume that non-zero payloads are
available to encode
* pointer and integer values. Since any 64-bit bit pattern where
the top 15 bits are
* all set represents a NaN with a non-zero payload, we can
Bug#638068: Re : initramfs-tools generates unbootable initrd.img on IA-64
Hello, To pass parameters to kernel, add an append= line in your elilo.conf file, just below the initrd= line. In the present case: append=debug=vc Please find attached the log that I've just recorded on a serial console passing debug=vc to kernel. Well, I don't see anything useful or different than without debug=vc. Emeric 2012/6/15 Aníbal Monsalve Salazar ani...@debian.org: On Fri, Jun 15, 2012 at 10:54:35AM +, maximilian attems wrote: Sorry for the time it took. According to your bug report klibc dash on ia64 has a working echo, so it's basic functionality should be good. It is not clear to me why the initramfs won't boot without busybox? It does here very well on x86 platforms. could you please list all the hooks that are shipped: ls /usr/share/initramfs-tools/hooks/ Also could you have a look at boot with the nont working initrmafs with supplied bootargument: debug=vc and no quiet please. It should show where in the boot process the initramfs hangs. thank you. -- maks # uname -a Linux debian 3.3.0-trunk-itanium #1 SMP Wed May 2 08:06:30 UTC 2012 ia64 GNU/Linux # ls /usr/share/initramfs-tools/hooks/ busybox dmsetup keymap klibc kmod thermal udev The photo at the web address below shows the output without the debug=vc kernel boot parameter. http://people.debian.org/~anibal/p1010539.jpg With the debug=vc kernel boot parameter there is no additional output. Just before the load of vmlinuz (at the ELILO boot prompt), I hit the tab key and typed LinuxOLD followed by debug=vc and it was ignored apparently. The prompt was: ELILO boot: Linux LinuxOLD (or a kernel file name: [[dev_name:/]path/]kernel_image cmdline options) ELILO boot: The machine is Dell PowerEdge 7250. I need to find out what's the dev_name of the EFI boot partition of the logical drive of the raid5. I tried debug=vc in elilo.conf and the system wouldn't boot and complained about that extra line in elilo.conf. My elilo.conf is below. ## elilo configuration file generated by elilo 3.12-4 # install=/usr/lib/elilo/elilo.efi # boot=/dev/sda1 # boot=/dev/disk/by-uuid/4DBC-29A7 delay=20 default=Linux relocatable image=/EFI/debian/vmlinuz label=Linux # root = /dev/sda2 root = UUID=e662a93c-2b14-46bc-82aa-5d29cc2b4db1 read-only initrd=/EFI/debian/initrd.img image=/EFI/debian/vmlinuz.old label=LinuxOLD # root = /dev/sda2 root = UUID=e662a93c-2b14-46bc-82aa-5d29cc2b4db1 read-only initrd=/EFI/debian/initrd.img.old Uncompressing Linux... done Loading file \EFI\debian\initrd.img...done [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.2.0-2-mckinley (Debian 3.2.19-1) (debian-kernel@l ists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-5) ) #1 SMP Fri Jun 1 22:37:41 UTC 2012 [0.00] EFI v1.10 by HP: SALsystab=0x3fb38000 ACPI 2.0=0x3fb2e000 SMBIOS= 0x3fb3a000 HCDP=0x3fb2c000 [0.00] booting generic kernel on platform hpzx1 [0.00] PCDP: v0 at 0x3fb2c000 [0.00] Explicit console=; ignoring PCDP [0.00] ACPI: RSDP 3fb2e000 00028 (v02 HP) [0.00] ACPI: XSDT 3fb2e02c 00094 (v01 HP zx6000 HP ) [0.00] ACPI: FACP 3fb36800 000F4 (v03 HP zx6000 HP ) [0.00] ACPI Warning: 32/64X length mismatch in Gpe0Block: 32/16 (2011062 3/tbfadt-529) [0.00] ACPI Warning: 32/64X length mismatch in Gpe1Block: 32/16 (2011062 3/tbfadt-529) [0.00] ACPI: DSDT 3fb2e0e0 05781 (v01 HP zx6000 0007 I NTL 02012044) [0.00] ACPI: FACS 3fb368f8 00040 [0.00] ACPI: SPCR 3fb36938 00050 (v01 HP zx6000 HP ) [0.00] ACPI: DBGP 3fb36988 00034 (v01 HP zx6000 HP ) [0.00] ACPI: APIC 3fb36a48 000B0 (v01 HP zx6000 HP ) [0.00] ACPI: SPMI 3fb369c0 00050 (v04 HP zx6000 HP ) [0.00] ACPI: CPEP 3fb36a10 00034 (v01 HP zx6000 HP ) [0.00] ACPI: SSDT 3fb33870 001D6 (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb33a50 00342 (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb33da0 00A16 (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb347c0 00A16 (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb351e0 00A16 (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb35c00 00A16 (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb36620 000EB (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: SSDT 3fb36710 000EF (v01 HP zx6000 0006 I NTL 02012044) [0.00] ACPI: Local APIC address c000fee0 [0.00] 2 CPUs
Bug#537572: gnome-settings-daemon can't connect to D-Bus and eats CPU on ia64 due to -Wl,-z-defs
Le 14 novembre 2011 23:51, Jonathan Nieder jrnie...@gmail.com a écrit :
So, to summarize, only libgconf.so and libsmartcard.so didn't need to
be replaced by recompiled versions without -z defs flag. I don't know
if it'll help further, but they can even be removed from
/usr/lib/gnome-settings-daemon-3.0 and both GDM3 and GNOME3 session
still run flawlessly.
Thanks, this is interesting.
Now for some stupid questions:
- does linking with gold instead (i.e., installing binutils-gold)
change the outcome?
Sorry for the late reply. Unfortunately, Gold isn't available on ia64,
neither in Wheezy, nor Sid. And I can't make it compile successfully
:-(
- does using -Wl,--no-undefined in place of -Wl,-z,defs change
anything?
No. But since -z defs and --no-undefined are the same (from the
manpage), that's a good thing ;-)
Presumably -Wl,--no-undefined -Wl,--error-unresolved-symbols errors out ---
what is the message when it does?
All the plugins complain about missing reference to
gnome_settings_plugin_get_type.
And some have additional missing references (mainly X11-related):
- a11y-keyboard: Xkb{Set|Get}Controls, XkbFreeKeyboard, XSync,
XkbQueryExtension, XkbSelectEvents;
- automount: XkbGetState;
- background: XInternAtom, XGetWindowProperty, XFree;
- clipboard: XSync, XInternAtom, XGetWindowProperty, XFree,
XChangeProperty, XConvertSelection, XSendEvent, XGetWindowAttributes,
XSelectInput, X{Set|Get}SelectionOwner, XCreateSimpleWindow,
XDestroyWindow, XExtendedMaxRequestSize, XMaxRequestSize, XIfEvent;
- keyboard: XkbFreeKeyboard, Xkb{Query|Use}Extension, XInternAtom,
XFree, XGetSelectionOwner, XAutoRepeat{On|Off}, XkbSetAutoRepeatRate,
XChangeKeyboardControl, XkbKeysymToModifiers, XkbSelectEventDetails,
XGetAtomName;
- mouse: floor, floorf, ceil, ceilf;
- print-notifications: notify_notification_new,
notify_notification_set_hint, notify_notification_show;
- xsettings: XInternAtom, XChangeProperty, XSendEvent, XSelectInput,
X{Set|Get}SelectionOwner, XCreateSimpleWindow, XDestroyWindow,
XIfEvent, X{Open|Close}Display, XResourceManagerString.
It's noteworthy than debian/rules top build script passes by default
--warn-unresolved-symbols to the linker, so the above missing
references are obviously hidden. I don't know if these missing
references are thus expected in the present context or if it's
expected that --warn-unresolved-symbols is passed to the linker rather
than --error-unresolved-symbols (default behavior from the manpage).
- what does using -z defs buy us when the error is demoted to a
warning by a later command-line option, anyway? Though I still
don't understand what is causing this code path to break.
Sorry Jonathan, my limited English doesn't allow me to understand this
last section. What do you mean by buy us?
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537572: GNOME settings daemon 3.0.3 binaries, with and without -z defs flag passed to the linker
2011/11/10 Jonathan Nieder jrnie...@gmail.com:
Thanks. What would be really useful is a linker command line and the
collection of object files (.o, .a, and .so, including relevant system
libraries from /usr/lib/) that it refers to, as described in
/usr/share/bug/binutils/presubj. Feel free to send these to me by
private mail.
OK, I'm preparing this.
[...]
It's noteworthy however than passing -z defs flag ends up in autoreconf'ing:
- ./plugins/media-keys/gsd-marshal.{h|c}
- ./ltmain.sh
- ./data/gnome-settings-daemon.desktop.in
as can be seen by diff'ing autoreconf.{before|after}.
Hm? When I diff the autoreconf.{before,after} that you sent, I don't
see that at all (the ltmain.sh changes as expected, but the other
files you mentioned were left alone).
Sorry, I was unclear.
autoreconf.{before|after} files exist in both .tbz archives and come
from the build process (this is really how they are named).
Now if you diff broken/autoreconf.before vs. working/autoreconf.before
(not autoreconf.before vs autoreconf.after), and similarly for
autoreconf.after, then you'll see the differences I was talking about.
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537572: Still the same with gnome-settings-daemon 2.30.2-4
Hi, FWIW amid the reports merged with this one, there is one person using i386 and another using mipsel. I don't know for i386 and mipsel, but here are my investigations for ia64. From the point of view of fixing this in binutils, it would be _very_ helpful to have a collection of object files and e.g. two linker command lines that should produce the same binary but do not. At the moment, a person investigating this has to get to know the gnome-settings-daemon build system and it is hard to debug or pass upstream. Alternatively, if this is a regression than a regression range would be helpful. gnome-settings-daemon first appears (at least on ia64) in Debian 5.0 Lenny. So I started with a fresh Lenny install on a spare HDD. From there, the older binutils package that I can install without breaking the whole system is binutils_2.17cvs20070426-1_ia64. Guess what? This old version already produces a broken gnome-settings-daemon with -z flag passed to the linker, and a working one without the flag :-( For further debugging, I can thus provide the locally rebuilt (with binutils_2.17cvs20070426-1_ia64) gnome-settings-daemon_2.22.2.1-2_ia64.deb binary packages with and without -z flag passed to linker. I've also kept the build directories of these two packages if preferred. As an alternative, I can also provide these packages but from a daily-updated Debian Testing Wheezy install, with up-to-date binutils and gnome-settings-daemon packages if preferred. About the gnome-settings-daemon build system, maybe Josselin can give us a clue? I have no idea how it works. Best regards, Émeric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537572: Still the same with gnome-settings-daemon 2.30.2-4
Hi, I've looked at the source package: the debian/build script still passes -z defs flags to ld, thus producing a broken binary, as expected :-( Regards, Émeric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638068: [bisected] initramfs-tools generates unbootable initrd.img on IA-64 platform (Itanium)
Hi, does initramfs-tools boot with BUSYBOX=no in initramfs.conf? Well, I don't know! Indeed, with BUSYBOX=no in initramfs.conf, initrd.img generation fails: root@longspeak:/# dpkg-reconfigure linux-image-3.0.0-1-mckinley Running depmod. Examining /etc/kernel/postinst.d. run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.0.0-1-mckinley /bo ot/vmlinuz-3.0.0-1-mckinley update-initramfs: Generating /boot/initrd.img-3.0.0-1-mckinley mv: cannot stat `/tmp/mkinitramfs_Z30F2f/bin/sh.shared': No such file or directo ry E: /usr/share/initramfs-tools/hooks/klibc failed with return 1. update-initramfs: failed for /boot/initrd.img-3.0.0-1-mckinley with 1. run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-3.0.0 -1-mckinley.postinst line 774. This is with initramfs-tools 0.99, as currently shipped in Testing. The same error occurs with source code currently in git. according to your aboves statement it might not as the shared klibc dash and not the static dash might end up in the initramfs? see ls /usr/lib/klibc/bin OK, here's where the 199144 bytes bin/sh exec comes from (size matches /usr/lib/klibc/bin/sh exec). Thanks for pointing this out. More on this later... Applying patch proposed in bug #628374 (initramfs-tools: Recent changes to hooks break busybox in initrd) to revert changes on busybox hook doesn't help. Simply reverting commit 8f8299d9ba017d2a5af853a52be37ee50c89fac2 from initramfs-tools v0.99 source code doesn't help either as resulting initramfs-tools binaries generate initrd.img failing to boot system with kernel panic, probably because of post-8f8299d9ba017d2a5af853a52be37ee50c89fac2 commits. The problem is still present in current initramfs-tools git repository. are you sure? Well, yes, I'm sure that the generated initramfs is unbootable. That being said, I've bisected the first bad commit. It's also possible that following commits fixed this issue, but other ones make it appear again, maybe with a different root cause. relevant apt source line is: deb http://jenkins.grml.org/debian initramfs-tools main please test that one, thank you. Still unbootable initramfs with this one. And initrd.img creation fails with the same error than with 0.99 and git with BUSYBOX=no in initramfs.conf. However, with BUSYBOX=yes, initrd.img can be generated successfully. If I look at its content, ls -l bin/ gives: -rwxr-xr-x 1 root root 199144 Aug 17 22:05 busybox lrwxrwxrwx 1 root root 7 Aug 17 22:05 sh - busybox Is it expected that bin/busybox in initramfs is in fact a copy of /usr/lib/klibc/bin/sh and not /bin/busybox? Indeed, ls -l on my system gives: -rwxr-xr-x 1 root root 1320720 Jul 25 16:17 /bin/busybox -rwxr-xr-x 1 root root 199144 Jul 27 17:32 /usr/lib/klibc/bin/sh Hope this helps, Émeric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638068: [bisected] initramfs-tools generates unbootable initrd.img on IA-64 platform (Itanium)
Package: initramfs-tools Version: 0.99 Severity: grave As stated in this thread http://lists.debian.org/debian-ia64/2011/08/msg1.html, Debian Wheezy Testing cannot be booted at all on IA-64 (current linux-image-3.0.0-1-mckinley in Testing depends on initramfs-tools 0.99, so initramfs-tools cannot be downgraded to previously working 0.98.8). Hence severity set to grave. Last message displayed on console is: [ 17.146492] Freeing unused kernel memory: 1024kB freed Loading, please wait... And then, nothing. Regression has been bisected to commit 8f8299d9ba017d2a5af853a52be37ee50c89fac2 (mkinitramfs: copy over on build instead of using symlink tree) from maximilian attems, 2011-02-21 (initramfs-tools v0.99 development cycle). Comparison of last good and first bad generated initrd.img ramdisks show that: - good one has bin/busybox and bin/sh, bin/sh being a soft link on bin/busybox and size of bin/busybox matching size of system /bin/busybox (1320720 bytes) - bad one has no bin/busybox, only bin/sh (executable, not a link) but size (199144 bytes) doesn't match size of system /bin/busybox (1320720 bytes). Indeed, analyzing hook-functions and hooks/busybox source code, it's my understanding that bin/sh should be a copy of system /bin/busybox and thus should have the same size, right? I don't know where this 199144 bytes executable comes from. Applying patch proposed in bug #628374 (initramfs-tools: Recent changes to hooks break busybox in initrd) to revert changes on busybox hook doesn't help. Simply reverting commit 8f8299d9ba017d2a5af853a52be37ee50c89fac2 from initramfs-tools v0.99 source code doesn't help either as resulting initramfs-tools binaries generate initrd.img failing to boot system with kernel panic, probably because of post-8f8299d9ba017d2a5af853a52be37ee50c89fac2 commits. The problem is still present in current initramfs-tools git repository. -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 18M Aug 16 21:45 /boot/initrd.img-2.6.39-2-mckinley -- /proc/cmdline BOOT_IMAGE=scsi1:/EFI/debian/vmlinuz.old root=UUID=59bf61ca-bdc4-4819-b6c7-5e6f8 057e8be ro -- resume RESUME=UUID=d550ead1-5755-40a6-af3a-07725fe4e688 -- /proc/filesystems ext4 fuseblk -- lsmod Module Size Used by fuse 148263 1 nfsd 580932 2 nfs 667482 0 lockd 148031 2 nfsd,nfs fscache78844 1 nfs auth_rpcgss80673 2 nfsd,nfs nfs_acl 5191 2 nfsd,nfs sunrpc401530 6 nfsd,nfs,lockd,auth_rpcgss,nfs_acl ipv6 667084 36 loop 30718 0 radeon 2088892 2 snd_fm801 35165 2 snd_ac97_codec184761 1 snd_fm801 ac97_bus1838 1 snd_ac97_codec ttm 117516 1 radeon drm_kms_helper 53852 1 radeon snd_pcm 147663 2 snd_fm801,snd_ac97_codec snd_page_alloc 11557 1 snd_pcm snd_tea575x_tuner 8774 1 snd_fm801 videodev 160214 1 snd_tea575x_tuner media 22901 1 videodev drm 318125 4 radeon,ttm,drm_kms_helper i2c_algo_bit 10968 1 radeon fm801_gp4776 0 gameport 15903 2 fm801_gp i2c_core 35751 5 radeon,drm_kms_helper,videodev,drm,i2c_algo_bit power_supply 16323 1 radeon evdev 20535 4 snd_opl3_lib 19238 1 snd_fm801 snd_timer 42224 2 snd_pcm,snd_opl3_lib snd_hwdep 13629 1 snd_opl3_lib snd_mpu401_uart13763 1 snd_fm801 snd_rawmidi40192 1 snd_mpu401_uart snd_seq_device 10749 2 snd_opl3_lib,snd_rawmidi snd 102026 13 snd_fm801,snd_ac97_codec,snd_pcm,snd_opl3_lib,s nd_timer,snd_hwdep,snd_mpu401_uart,snd_rawmidi,snd_seq_device soundcore 10343 1 snd ext4 554604 1 mbcache12842 1 ext4 jbd2 118997 1 ext4 crc16 1479 1 ext4 sd_mod 75886 3 crc_t10dif 1420 1 sd_mod usbhid 61155 0 hid 134780 1 usbhid sg 47353 0 sr_mod 32745 0 cdrom 73444 1 sr_mod ata_generic 5671 0 ohci_hcd 53106 0 pata_cmd64x10096 0 libata349825 2 ata_generic,pata_cmd64x mptspi 27375 2 mptscsih 38872 1 mptspi ehci_hcd 91574 0 mptbase 116134 2 mptspi,mptscsih scsi_transport_spi 44772 1 mptspi usbcore 284414 4 usbhid,ohci_hcd,ehci_hcd scsi_mod 252243 7 sd_mod,sg,sr_mod,libata,mptspi,mptscsih,scsi_tra nsport_spi tg3 299933 0 e100 64313 0 mii 8419 1 e100 libphy 36137 1 tg3 -- /etc/initramfs-tools/modules -- /etc/kernel-img.conf #
Bug#537572: Still the same with gnome-settings-daemon 2.30.2-3
Hi, I've looked at the source package: the debian/build script still passes -z defs flags to ld, thus producing a broken binary, as expected :-( Regards, Émeric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620546: apt 0.8.13.1 fixed the problem
Hi, FYI, manually installing apt 0.8.13.1 (dated 2011-04-03) using dpkg -i made apt happy again. Regards, Émeric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620874: binutils: -z defs ld flag breaks gnome-settings-daemon on IA-64
Package: binutils Version: 2.20.1-16 Severity: critical As explained in this post (http://lists.debian.org/debian-ia64/2011/03/msg00017.html), gnome-settings-daemon is broken on IA-64 (Itanium) since release 2.24.1-1 dated 2008-12-30, not because of a source code change, but because of a change in the flags passed to ld by the debian/rules build script of the gnome-settings-daemon source package. Simply removing -Wl,-z,defs from the LDFLAGS of the debian/rules script produces a working gnome-settings-daemon binary. This has been checked with current gnome-settings-daemon-2.30.2-2 and gnome-settings-daemon-2.24.1-1 (first broken release). Cross-testing by adding this flag to gnome-settings-daemon-2.22.2.1-2 (last working release) produces a broken binary, proving that -z defs flag is the culprit. What's unclear to me: - is this issue limited to gnome-settings-daemon or does it reveal something more serious and other packages built with -z defs flag are affected too (hence this bug report)? - if other packages are affected too, is this issue specific to IA-64 or not? From http://www.debian.org/Bugs/Developer#severities, I've set bug severity to critical, as ld breaks an unrelated software (gnome-settings-daemon in the present case). By the way, with currently broken gnome-settings-daemon-2.30.2-2 and gdm3 window manager, CPU power is completely eaten by running instances of gnome-settings-daemon. Even worse, each time a user logs in/off, additional gnome-settings-daemon processes are forked, leading to a completely unusable system. And unfortunately, a standard user doesn't have sufficient permissions to kill the CPU-eating gnome-settings-daemon processes (although this was possible with gdm; but gdm will be dropped in next Debian Wheezy). -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: ia64 Kernel: Linux 2.6.32-5-mckinley (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages binutils depends on: ii libc6.1 2.11.2-11Embedded GNU C Library: Shared lib ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime binutils recommends no packages. Versions of packages binutils suggests: pn binutils-doc none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620874: binutils: -z defs ld flag breaks gnome-settings-daemon on IA-64
Hi, -z defs means to disallow undefined symbols in object files. Are you sure that there is not some undefined symbol in an object file and this is not build system/runtime behavior fallout from that? I know nothing about gnome-settings-daemon code and related software, so can't make any assumption on potential undefined symbol. By the way, with currently broken gnome-settings-daemon-2.30.2-2 and gdm3 window manager, CPU power is completely eaten by running instances of gnome-settings-daemon. Even worse, each time a user logs in/off, additional gnome-settings-daemon processes are forked, leading to a completely unusable system. These are symptoms and do not in themselves sound like something a linker would do. It would be very nice if someone could track down the underlying problem. Sorry if I was unclear. These symptoms only surface with broken gnome-settings-daemon binary. Simply removing the offending -z defs flag from LDFLAGS of the debian/rules build script of the gnome-settings-daemon source package produces a working binary, making these symptoms disappear. Thanks for writing, Thanks for answering :-) Jonathan Émeric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620874: binutils: -z defs ld flag breaks gnome-settings-daemon on IA-64
Hello again, Thanks for your hard work tracking this down, and thanks for bringing it to our attention. I'm going to merge this with the existing gnome-settings-daemon bug, so the problem is tracked in one place. Of course it is possible there is a binutils involved here somewhere. If that turns out to be the case, please feel free to unmerge the bug again and reassign. OK. For completeness about potential unresolved symbols, here's a partial output of fakeroot debian/rules binary of current gnome-settings-daemon 2.30.2-2 source package on my system showing some unresolvable reference to symbols: dpkg-shlibdeps: warning: debian/gnome-settings-daemon/usr/lib/gnome-settings-daemon-2.0/libtyping-break.so contains an unresolvable reference to symbol gnome_settings_plugin_get_type: it's probably a plugin. dpkg-shlibdeps: warning: debian/gnome-settings-daemon/usr/lib/gnome-settings-daemon-2.0/libxrandr.so contains an unresolvable reference to symbol XGrabKey: it's probably a plugin. dpkg-shlibdeps: warning: 3 other similar warnings have been skipped (use -v to see them all). dpkg-shlibdeps: warning: debian/gnome-settings-daemon/usr/lib/gnome-settings-daemon-2.0/libkeybindings.so contains an unresolvable reference to symbol gnome_settings_plugin_get_type: it's probably a plugin. dpkg-shlibdeps: warning: debian/gnome-settings-daemon/usr/lib/gnome-settings-daemon-2.0/libhousekeeping.so contains an unresolvable reference to symbol gnome_settings_plugin_get_type: it's probably a plugin. dpkg-shlibdeps: warning: debian/gnome-settings-daemon/usr/lib/gnome-settings-daemon-2.0/libxrdb.so contains an unresolvable reference to symbol gnome_settings_plugin_get_type: it's probably a plugin. dpkg-shlibdeps: warning: debian/gnome-settings-daemon/usr/lib/gnome-settings-daemon-2.0/libclipboard.so contains an unresolvable reference to symbol XGetSelectionOwner: it's probably a plugin. dpkg-shlibdeps: warning: 16 other similar warnings have been skipped (use -v to see them all). dpkg-shlibdeps: warning: debian/gnome-settings-daemon/usr/lib/gnome-settings-daemon-2.0/libmouse.so contains an unresolvable reference to symbol gnome_settings_plugin_get_type: it's probably a plugin. dpkg-shlibdeps: warning: debian/gnome-settings-daemon/usr/lib/gnome-settings-daemon-2.0/libbackground.so contains an unresolvable reference to symbol XInternAtom: it's probably a plugin. dpkg-shlibdeps: warning: 3 other similar warnings have been skipped (use -v to see them all). dpkg-shlibdeps: warning: debian/gnome-settings-daemon/usr/lib/gnome-settings-daemon-2.0/libfont.so contains an unresolvable reference to symbol XGetSelectionOwner: it's probably a plugin. dpkg-shlibdeps: warning: 11 other similar warnings have been skipped (use -v to see them all). dpkg-shlibdeps: warning: debian/gnome-settings-daemon/usr/lib/gnome-settings-daemon-2.0/liba11y-keyboard.so contains an unresolvable reference to symbol XkbUseExtension: it's probably a plugin. dpkg-shlibdeps: warning: 8 other similar warnings have been skipped (use -v to see them all). dpkg-shlibdeps: warning: debian/gnome-settings-daemon/usr/lib/gnome-settings-daemon-2.0/libxsettings.so contains an unresolvable reference to symbol XInternAtom: it's probably a plugin. dpkg-shlibdeps: warning: 12 other similar warnings have been skipped (use -v to see them all). dpkg-shlibdeps: warning: debian/gnome-settings-daemon/usr/lib/gnome-settings-daemon-2.0/libsound.so contains an unresolvable reference to symbol gnome_settings_plugin_get_type: it's probably a plugin. dpkg-shlibdeps: warning: debian/gnome-settings-daemon/usr/lib/gnome-settings-daemon-2.0/libkeyboard.so contains an unresolvable reference to symbol XInternAtom: it's probably a plugin. dpkg-shlibdeps: warning: 14 other similar warnings have been skipped (use -v to see them all). Will this help? Cheers, Jonathan Regards, Émeric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608893: Same problem with epiphany-browser 2.30.6-1
Hi,
I don't know if the root cause is the same, but here's the stack trace
I'm recording with current epiphany-browser in Debian Squeeze on an
Itanium workstation.
emeric@longspeak:~$ gdb epiphany-browser
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as ia64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/bin/epiphany-browser...Reading symbols from
/usr/lib/debug/usr/bin/epiphany-browser...done.
(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/epiphany-browser
[Thread debugging using libthread_db enabled]
[New Thread 0x2bf430f0 (LWP 7473)]
[New Thread 0x2cacb0f0 (LWP 7474)]
epiphany-browse(7470): unaligned access to 0x2bf7ac4e,
ip=0x2196eeb0
epiphany-browse(7470): unaligned access to 0x2bf7acb6,
ip=0x2196edb0
epiphany-browse(7470): unaligned access to 0x2bf7ad1e,
ip=0x2196eeb0
epiphany-browse(7470): unaligned access to 0x2bf7ad26,
ip=0x2196eeb0
epiphany-browse(7470): unaligned access to 0x2bf7ad2e,
ip=0x2196eeb0
[New Thread 0x2d85f0f0 (LWP 7475)]
** Message: console message: undefined @0: 1.4450535554832405e-154
[New Thread 0x2e7bf0f0 (LWP 7476)]
[New Thread 0x2efbf0f0 (LWP 7477)]
[New Thread 0x2f8bf0f0 (LWP 7478)]
[New Thread 0x2000147ff0f0 (LWP 7479)]
[New Thread 0x200014fff0f0 (LWP 7480)]
Program received signal SIGSEGV, Segmentation fault.
JSObjectCallAsFunction (ctx=0x2bf79748, object=0x0,
thisObject=value optimized out, argumentCount=1,
arguments=0x6f80d980, exception=0x0)
at ../JavaScriptCore/API/JSObjectRef.cpp:388
388 ../JavaScriptCore/API/JSObjectRef.cpp: No such file or directory.
in ../JavaScriptCore/API/JSObjectRef.cpp
Current language: auto
The current source language is auto; currently c++.
(gdb) thread apply all bt full
Thread 9 (Thread 0x200014fff0f0 (LWP 7480)):
#0 0xa0010721 in __kernel_syscall_via_break ()
No symbol table info available.
#1 0x24677660 in __pthread_cond_timedwait (cond=0x60309ca0,
mutex=0x60110a60, abstime=0x200014ffe6e0)
at pthread_cond_timedwait.c:160
_b7 = 0xa0010a00
_out2 = 11
_r15 = 1246
_retval = value optimized out
_out3 = 2305843009566008976
_out0 = 6917529027644267684
_r8 = value optimized out
_r10 = value optimized out
_out1 = 128
rt = {tv_sec = 0, tv_nsec = 218601523}
futex_val = 11
buffer = {__routine = 0x272166a0, __arg = 0x200014ffe6c0,
__canceltype = -2147352576, __prev = 0x0}
cbuffer = {oldtype = 0, cond = 0x60309ca0,
mutex = 0x60110a60, bc_seq = 0}
result = value optimized out
pshared = 0
err = value optimized out
val = value optimized out
seq = 3
#2 0x242886d0 in g_cond_timed_wait_posix_impl (
cond=0x60309ca0, entered_mutex=0x60110a60,
abs_time=0x200014ffe6f0)
at
/build/buildd-glib2.0_2.24.2-1-ia64-HJZXOu/glib2.0-2.24.2/gthread/gthread-posix.c:242
result = value optimized out
end_time = {tv_sec = 1296086837, tv_nsec = 449181000}
timed_out = value optimized out
__PRETTY_FUNCTION__ = g_cond_timed_wait_posix_impl
#3 0x242bc400 in g_async_queue_pop_intern_unlocked (
queue=0x60110a30, try=0, end_time=0x200014ffe6f0)
at
/build/buildd-glib2.0_2.24.2-1-ia64-HJZXOu/glib2.0-2.24.2/glib/gasyncqueue.c:365
retval = value optimized out
__PRETTY_FUNCTION__ = g_async_queue_pop_intern_unlocked
#4 0x24386130 in g_thread_pool_wait_for_new_task (
data=0x60114f80)
at
/build/buildd-glib2.0_2.24.2-1-ia64-HJZXOu/glib2.0-2.24.2/glib/gthreadpool.c:270
end_time = {tv_sec = 1296086837, tv_usec = 449181}
#5 g_thread_pool_thread_proxy (data=0x60114f80)
at
/build/buildd-glib2.0_2.24.2-1-ia64-HJZXOu/glib2.0-2.24.2/glib/gthreadpool.c:304
task = 0x602ab6a0
pool = 0x60114f80
#6 0x24380d30 in g_thread_create_proxy (data=value optimized out)
at
/build/buildd-glib2.0_2.24.2-1-ia64-HJZXOu/glib2.0-2.24.2/glib/gthread.c:1893
__PRETTY_FUNCTION__ = g_thread_create_proxy
#7 0x2466abc0 in start_thread (arg=0x200014fff0f0)
at pthread_create.c:302
pd = 0x200014fff0f0
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {2305843009566009072,
2305843009290158648, 0, 2674341354693439, 0, 0, 0, 0,
Bug#691576: linux-image-mckinley 3.11+54 breaks gdb again
> Bug#691576: linux-image-mckinley 3.11+54 breaks gdb again debian-bugs-rc -- Thread -- -- Date -- Bug#691576: linux-image-mckinley 3.11+54 breaks gdb again Émeric MASCHINO Reply via email to
