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
On Sun, Jan 19, 2014 at 08:40:27PM +0100, Émeric MASCHINO wrote: [1] https://lists.debian.org/debian-68k/2013/05/msg00065.html === BTW, why is it archived on debian-68k? Because it was send to debian-ports@lists and not debian-ia64@lists like this, and debian-ports goes to all the porter lists including m68k and ia64. Kurt -- 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
On Sun, 2014-01-12 at 19:15 +0100, Émeric MASCHINO wrote: 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: [...] [ 32.239142] Unable to handle kernel paging request at virtual address 40039f8 0a032 [ 32.334142] systemd-udevd[47]: Oops 11012296146944 [1] [ 32.338131] Modules linked in: [ 32.338131] [ 32.338131] Pid: 47, CPU 0, comm:systemd-udevd [ 32.338131] psr : 1210085a6010 ifs : 8001 ip : [a001002 41e51]Not tainted (3.2.0-4-mckinley Debian 3.2.51-1a~test) [ 32.338131] ip is at mntget+0x11/0x60 So this is a crash, not an incompatibility with the newer systemd. [...] I really need to know whether -O1 works for 3.2; I can't just speculatively change it in a stable update. I understand that. Can you test the 3.2 kernel with sysvinit, in case this is a bug that's specifically provoked by systemd? Ben. -- Ben Hutchings Quantity is no substitute for quality, but it's the only one we've got. signature.asc Description: This is a digitally signed message part
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
On Sun, 2014-01-12 at 21:16 +0100, Émeric MASCHINO wrote: 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? 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. I don't know whether current gdm will work correctly under sysvinit but you can at least test that you can boot that system and log in on a text console. Ben. -- Ben Hutchings Quantity is no substitute for quality, but it's the only one we've got. signature.asc Description: This is a digitally signed message part
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
On Sun, 2014-01-12 at 22:30 +0100, Émeric MASCHINO wrote: 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? 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. Ben. -- Ben Hutchings Quantity is no substitute for quality, but it's the only one we've got. signature.asc Description: This is a digitally signed message part
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
On Sun, 2014-01-12 at 22:48 +0100, Émeric MASCHINO wrote: 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? 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.) Ben. -- Ben Hutchings Quantity is no substitute for quality, but it's the only one we've got. signature.asc Description: This is a digitally signed message part
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
On Mon, 2014-01-06 at 10:15 +0100, Émeric MASCHINO wrote: 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). [...] 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? I really need to know whether -O1 works for 3.2; I can't just speculatively change it in a stable update. Ben. -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo. signature.asc Description: This is a digitally signed message part
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
On Fri, Dec 20, 2013 at 09:15:23PM +0100, Émeric MASCHINO wrote: 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? Tony Luck at Intel is still maintainer for ia64 but I don't think even he's working full time on it. 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. HP focuses on propietary operating systems that it can maintain by itself and which are now exclusive to Itanium - HP-UX, NonStop and OpenVMS. I assume they gave up on Linux/ia64 once the enterprise distributors did. 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? I have no idea as no-one has reported their results yet. Do you know if GCC regressions observed by Will Deacon are documented somewhere? No, you'd have to ask him. Ben. -- Ben Hutchings The generation of random numbers is too important to be left to chance. - Robert Coveyou -- 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
I kind of wonder if it has anything to do with compiler code generation; I don't remember if you checked whether -O[0,1,2,3] on the kernel changed anything. The appearance is so random, but when it does appear, it's stuck for that version (i.e. not just a race issue that is hard to repro). Patrick On Thu, Dec 12, 2013 at 3:20 PM, Émeric MASCHINO emeric.masch...@gmail.comwrote: 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-ia64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caa9xbm5h_sn+vgutc6pgswfrtay0ftapo1a-g6lq5xhee8...@mail.gmail.com
Bug#691576: GDB still broken with 3.11.10-1
On Thu, Dec 12, 2013 at 10:20:30PM +0100, Émeric MASCHINO wrote: Ben, I was not reporting this as a reproach, I understood that. 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 Failing to see a pattern here. :-/ [...] 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? [...] 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. 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/ Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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: GDB still broken with 3.11.10-1
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
