Re: Sparc release requalification
On Sat, Dec 05, 2009 at 02:00:33PM +0100, Josip Rodin wrote: I've tried that one right now, and this is what I got: [ 41.596742] Brought up 2 CPUs [ 41.744948] regulator: core version 0.5 [ 41.795563] NET: Registered protocol family 16 [ There it hung. Doesn't look much different from before. [...] Just a fix confirmation for our mailing list - http://bugs.debian.org/572442 -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100304093007.ga24...@orion.carnet.hr
Re: Sparc release requalification
On Tue, Dec 01, 2009 at 11:57:45PM +0100, Josip Rodin wrote: On Tue, Dec 01, 2009 at 09:42:12PM +, Jurij Smakov wrote: http://www.backports.org/debian/pool/main/l/linux-2.6/linux-image-2.6.30-bpo.2-sparc64-smp_2.6.30-8~bpo50+1_sparc.deb I've tried everything to reproduce this. I've tried building 2.6.31.6 -stable from Josip's config using Debian stable's compiler (gcc-4.3.2) I think you need to build with the gcc from unstable to reproduce the failure. Lenny kernels have been booting fine on my box (SunBlade 1000), unstable kernels started failing about 3 months ago. Hm, OK, but that doesn't help explain why that exact image, a lenny backport, didn't work here... JFTR the difference would be 4.3.2 vs. 4.3.4 per http://packages.debian.org/gcc-4.3 I've upgraded to the latest unstable on my box today, and this pulled in the stock Debian 2.6.31 kernel, which, amusingly, boots just fine: ju...@debian:~$ uname -a Linux debian 2.6.31-1-sparc64-smp #1 SMP Mon Nov 16 14:12:48 UTC 2009 sparc GNU/Linux ju...@debian:~$ zcat /boot/vmlinuz-2.6.31-1-sparc64-smp | strings | grep gcc | head -1 Linux version 2.6.31-1-sparc64-smp (Debian 2.6.31-2) (b...@decadent.org.uk) (gcc version 4.3.4 (Debian 4.3.4-6) ) #1 SMP Mon Nov 16 14:12:48 UTC 2009 Can you try whether it works for you as well? Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Sat, Dec 05, 2009 at 12:18:22PM +, Jurij Smakov wrote: Hm, OK, but that doesn't help explain why that exact image, a lenny backport, didn't work here... I've upgraded to the latest unstable on my box today, and this pulled in the stock Debian 2.6.31 kernel, which, amusingly, boots just fine: ju...@debian:~$ uname -a Linux debian 2.6.31-1-sparc64-smp #1 SMP Mon Nov 16 14:12:48 UTC 2009 sparc GNU/Linux ju...@debian:~$ zcat /boot/vmlinuz-2.6.31-1-sparc64-smp | strings | grep gcc | head -1 Linux version 2.6.31-1-sparc64-smp (Debian 2.6.31-2) (b...@decadent.org.uk) (gcc version 4.3.4 (Debian 4.3.4-6) ) #1 SMP Mon Nov 16 14:12:48 UTC 2009 Can you try whether it works for you as well? I've tried that one right now, and this is what I got: boot: Linux Allocated 8 Megs of memory at 0x4000 for kernel Uncompressing image... Loaded kernel version 2.6.31 Loading initial ramdisk (7069568 bytes at 0x12 phys, 0x40C0 virt)... / [0.00] PROMLIB: Sun IEEE Boot Prom 'OBP 4.11.4 2003/07/23 08:04' [0.00] PROMLIB: Root node compatible: [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.31-1-sparc64-smp (Debian 2.6.31-2) (b...@decadent.org.uk) (gcc version 4.3.4 (Debian 4.3.4-6) ) #1 SMP Mon Nov 16 14:12:48 UTC 2009 [0.00] console [earlyprom0] enabled [0.00] ARCH: SUN4U [0.00] Ethernet address: 00:03:ba:5a:53:a5 [0.00] Kernel: Using 2 locked TLB entries for main kernel image. [0.00] Remapping the kernel... done. [0.00] OF stdout device is: /p...@1e,60/i...@7/ser...@0,3f8 [0.00] PROM: Built device tree with 85794 bytes of memory. [0.00] Top of RAM: 0x123fedc000, Total RAM: 0xffed [0.00] Memory hole size: 70656MB [0.00] [0002-f840] page_structs=131072 node=0 entry=0/0 [0.00] [0002-f880] page_structs=131072 node=0 entry=1/0 [0.00] [00020400-f8c0] page_structs=131072 node=0 entry=16/0 [0.00] [00020400-f8000100] page_structs=131072 node=0 entry=17/0 [0.00] [00022000-f8000140] page_structs=131072 node=0 entry=128/0 [0.00] [00022000-f8000180] page_structs=131072 node=0 entry=129/0 [0.00] [00022400-f80001c0] page_structs=131072 node=0 entry=144/0 [0.00] [00022400-f8000200] page_structs=131072 node=0 entry=145/0 [0.00] Zone PFN ranges: [0.00] Normal 0x - 0x0091ff6e [0.00] Movable zone start PFN for each node [0.00] early_node_map[7] active PFN ranges [0.00] 0: 0x - 0x0002 [0.00] 0: 0x0010 - 0x0012 [0.00] 0: 0x0080 - 0x0082 [0.00] 0: 0x0090 - 0x0091f7ff [0.00] 0: 0x0091f800 - 0x0091fef3 [0.00] 0: 0x0091fef5 - 0x0091ff5e [0.00] 0: 0x0091ff61 - 0x0091ff6e [0.00] Booting Linux... [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 449385 [0.00] Kernel command line: root=/dev/md1 ro rootdelay=10 console=ttyS0,9600n1 [0.00] PID hash table entries: 4096 (order: 12, 32768 bytes) [0.00] Dentry cache hash table entries: 524288 (order: 9, 4194304 bytes)[0.00] Inode-cache hash table entries: 262144 (order: 8, 2097152 bytes) [0.00] Memory: 4140168k available (3440k kernel code, 1336k data, 216k init) [f800,00123fedc000] [0.00] NR_IRQS:255 [0.00] clocksource: mult[53] shift[16] [0.00] clockevent: mult[3126e97] shift[32] [ 40.900976] Console: colour dummy device 80x25 [ 41.039420] Calibrating delay using timer specific routine.. 24.01 BogoMIPS (lpj=48029) [ 41.144787] Security Framework initialized [ 41.198547] SELinux: Disabled at boot. [ 41.248905] Mount-cache hash table entries: 512 [ 41.308793] Initializing cgroup subsys ns [ 41.361476] Initializing cgroup subsys cpuacct [ 41.419802] Initializing cgroup subsys devices [ 41.478128] Initializing cgroup subsys freezer [ 41.536458] Initializing cgroup subsys net_cls [ 41.596728] CPU 0: synchronized TICK with master CPU (last diff 1 cycles, maxerr 6 cycles) [ 41.596742] Brought up 2 CPUs [ 41.744948] regulator: core version 0.5 [ 41.795563] NET: Registered protocol family 16 [ There it hung. Doesn't look much different from before. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Mon, Nov 30, 2009 at 09:23:36PM -0800, David Miller wrote: From: Josip Rodin j...@entuzijast.net Date: Mon, 23 Nov 2009 23:40:28 +0100 http://www.backports.org/debian/pool/main/l/linux-2.6/linux-image-2.6.30-bpo.2-sparc64-smp_2.6.30-8~bpo50+1_sparc.deb To extract, use: dpkg-deb -x linux-image-2.6.30-bpo.2-sparc64-smp_2.6.30-8~bpo50+1_sparc.deb newdir And then you have newdir/boot/vmlinuz-2.6.30-bpo.2-sparc64-smp etc I've tried everything to reproduce this. I've tried building 2.6.31.6 -stable from Josip's config using Debian stable's compiler (gcc-4.3.2) I think you need to build with the gcc from unstable to reproduce the failure. Lenny kernels have been booting fine on my box (SunBlade 1000), unstable kernels started failing about 3 months ago. I might have some time over the weekend to build the current unstable kernel with both stable and unstable gcc to verify that it's unstable gcc which causes problems. I've also tried the image in that dpkg. All of them boot fine on my two similarly configured UltraSPARC-IIIi systems. I'll try to think some more about this, but meanwhile if you have some means by which to make your V240 available to me online to do somet debugging that would be really useful. You can see from Hermann's providing access to his V480 to me once I have access I tend to fix the bug within a day or two :-) -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Tue, Dec 01, 2009 at 09:42:12PM +, Jurij Smakov wrote: http://www.backports.org/debian/pool/main/l/linux-2.6/linux-image-2.6.30-bpo.2-sparc64-smp_2.6.30-8~bpo50+1_sparc.deb I've tried everything to reproduce this. I've tried building 2.6.31.6 -stable from Josip's config using Debian stable's compiler (gcc-4.3.2) I think you need to build with the gcc from unstable to reproduce the failure. Lenny kernels have been booting fine on my box (SunBlade 1000), unstable kernels started failing about 3 months ago. Hm, OK, but that doesn't help explain why that exact image, a lenny backport, didn't work here... JFTR the difference would be 4.3.2 vs. 4.3.4 per http://packages.debian.org/gcc-4.3 -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
From: Josip Rodin j...@entuzijast.net Date: Mon, 23 Nov 2009 23:40:28 +0100 http://www.backports.org/debian/pool/main/l/linux-2.6/linux-image-2.6.30-bpo.2-sparc64-smp_2.6.30-8~bpo50+1_sparc.deb To extract, use: dpkg-deb -x linux-image-2.6.30-bpo.2-sparc64-smp_2.6.30-8~bpo50+1_sparc.deb newdir And then you have newdir/boot/vmlinuz-2.6.30-bpo.2-sparc64-smp etc I've tried everything to reproduce this. I've tried building 2.6.31.6 -stable from Josip's config using Debian stable's compiler (gcc-4.3.2) I've also tried the image in that dpkg. All of them boot fine on my two similarly configured UltraSPARC-IIIi systems. I'll try to think some more about this, but meanwhile if you have some means by which to make your V240 available to me online to do somet debugging that would be really useful. You can see from Hermann's providing access to his V480 to me once I have access I tend to fix the bug within a day or two :-) -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Wed, Nov 25, 2009 at 02:53:00PM -0800, David Miller wrote: I'm confused now :-) So does gcc-4.1.3 produce the bad kernels or does gcc-4.3.2? No, Hermann's mail was not relevant, the new NMI code did not exist in 2.6.26. I asked a question which was a choice between two non-booleans, and you resonded with a boolean. Please answer my question :-) Sorry :) 2.6.26 compiled by gcc 4.1 boots on our v240s. 2.6.28+ compiled by gcc 4.3 does not boot on our v240s. I have not yet tried to compile 2.6.28+ with 4.1, or vice versa. On related note, gcc 4.4 is scheduled to be released in the next Debian stable as well, so gcc 4.1 is definitely on its way out... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Tue, Nov 24, 2009 at 10:40:47PM -0800, David Miller wrote: OK. Yours has gcc 4.2.4, and our ones have gcc 4.3.2 (that we shipped as stable :) I also just tried a newer packaged image, and it has the same issue. I just tossed lenny onto my main build system and I will try to reproduce this and track it down. FYI: lenny uses gcc 4.1.3 for their normal build at least on amd64 and sparc systems: Linux version 2.6.26-2-sparc64-smp (Debian 2.6.26-19lenny2) (da...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Thu Nov 5 03:34:29 UTC 2009 -- Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg IWR; INF 368; 69120 Heidelberg; Tel: (06221)54-8236 Fax: -5224 Email: hermann.la...@iwr.uni-heidelberg.de -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Wed, Nov 25, 2009 at 09:36:33AM +0100, Hermann Lauer wrote: OK. Yours has gcc 4.2.4, and our ones have gcc 4.3.2 (that we shipped as stable :) I also just tried a newer packaged image, and it has the same issue. I just tossed lenny onto my main build system and I will try to reproduce this and track it down. FYI: lenny uses gcc 4.1.3 for their normal build at least on amd64 and sparc systems: 2.6.26 didn't have the NMI watchdog code anyway. Besides, 4.4 is on the way already, so old version talk is moot. Let's just let Dave do his magic :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
From: Hermann Lauer hermann.la...@iwr.uni-heidelberg.de Date: Wed, 25 Nov 2009 09:36:33 +0100 On Tue, Nov 24, 2009 at 10:40:47PM -0800, David Miller wrote: OK. Yours has gcc 4.2.4, and our ones have gcc 4.3.2 (that we shipped as stable :) I also just tried a newer packaged image, and it has the same issue. I just tossed lenny onto my main build system and I will try to reproduce this and track it down. FYI: lenny uses gcc 4.1.3 for their normal build at least on amd64 and sparc systems: Linux version 2.6.26-2-sparc64-smp (Debian 2.6.26-19lenny2) (da...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Thu Nov 5 03:34:29 UTC 2009 I'm confused now :-) So does gcc-4.1.3 produce the bad kernels or does gcc-4.3.2? I built Linus's current tree under Lenny and that booted up perfectly on my Niagara2 box. Also, please increase CONFIG_NR_CPUS to 256 in your SMP builds on sparc64 in Debian. I'm missing most of my cpus with the Debian built kernels :-) Probably I've mentioned this before :-) -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Wed, Nov 25, 2009 at 12:09:13PM -0800, David Miller wrote: From: Hermann Lauer hermann.la...@iwr.uni-heidelberg.de Date: Wed, 25 Nov 2009 09:36:33 +0100 On Tue, Nov 24, 2009 at 10:40:47PM -0800, David Miller wrote: OK. Yours has gcc 4.2.4, and our ones have gcc 4.3.2 (that we shipped as stable :) I also just tried a newer packaged image, and it has the same issue. I just tossed lenny onto my main build system and I will try to reproduce this and track it down. FYI: lenny uses gcc 4.1.3 for their normal build at least on amd64 and sparc systems: Linux version 2.6.26-2-sparc64-smp (Debian 2.6.26-19lenny2) (da...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Thu Nov 5 03:34:29 UTC 2009 I'm confused now :-) So does gcc-4.1.3 produce the bad kernels or does gcc-4.3.2? No, Hermann's mail was not relevant, the new NMI code did not exist in 2.6.26. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
From: Josip Rodin j...@entuzijast.net Date: Wed, 25 Nov 2009 21:36:24 +0100 On Wed, Nov 25, 2009 at 12:09:13PM -0800, David Miller wrote: I'm confused now :-) So does gcc-4.1.3 produce the bad kernels or does gcc-4.3.2? No, Hermann's mail was not relevant, the new NMI code did not exist in 2.6.26. I asked a question which was a choice between two non-booleans, and you resonded with a boolean. Please answer my question :-) -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
From: Josip Rodin j...@entuzijast.net Date: Mon, 23 Nov 2009 23:40:28 +0100 On Mon, Nov 23, 2009 at 02:32:04PM -0800, David Miller wrote: Something like that. It could also just be compiled differently by your gcc and expose some race or bug. OK. Yours has gcc 4.2.4, and our ones have gcc 4.3.2 (that we shipped as stable :) I also just tried a newer packaged image, and it has the same issue. I just tossed lenny onto my main build system and I will try to reproduce this and track it down. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
From: Josip Rodin j...@entuzijast.net Date: Sat, 31 Oct 2009 17:48:06 +0100 No idea, I got stuck there and reverted to .28. Then the machine started exhibiting some other issues so it was reverted to .26. :/ Sorry for dropping the ball on this one. As promised long ago, here is a 2.6.31.6 kernel built with you 2.6.31 config file. Let me know if it exhibits the bootup problem so we can diagnose further: http://vger.kernel.org/~davem/josip_test_2631_6.img Thanks! -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
From: Hermann Lauer hermann.la...@iwr.uni-heidelberg.de Date: Mon, 23 Nov 2009 22:11:27 +0100 On Mon, Nov 23, 2009 at 12:24:46PM -0800, David Miller wrote: As promised long ago, here is a 2.6.31.6 kernel built with you 2.6.31 config file. Let me know if it exhibits the bootup problem so we can diagnose further: http://vger.kernel.org/~davem/josip_test_2631_6.img Tested on my SunFire480, output until hang is attached. Thanks for testing. Although it wasn't meant to fix your problem :-) -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Mon, Nov 23, 2009 at 12:24:46PM -0800, David Miller wrote: As promised long ago, here is a 2.6.31.6 kernel built with you 2.6.31 config file. Let me know if it exhibits the bootup problem so we can diagnose further: http://vger.kernel.org/~davem/josip_test_2631_6.img Tested on my SunFire480, output until hang is attached. Greetings Hermann Rebooting with command: boot gem:dhcp Boot device: /p...@8,60/netw...@2:dhcp File and args: Timed out waiting for BOOTP/DHCP reply Timed out waiting for BOOTP/DHCP reply Timed out waiting for BOOTP/DHCP reply \ PROMLIB: Sun IEEE Boot Prom 'OBP 4.22.34 2007/07/23 13:01' PROMLIB: Root node compatible: Linux version 2.6.31.6 (da...@huronp11) (gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)) #2 SMP Mon Nov 23 12:18:05 PST 2009 console [earlyprom0] enabled ARCH: SUN4U Ethernet address: 00:03:ba:29:7c:9f Kernel: Using 1 locked TLB entries for main kernel image. Remapping the kernel... done. OF stdout device is: /p...@9,70/e...@1/rsc-cons...@1,3083f8 PROM: Built device tree with 104327 bytes of memory. Top of RAM: 0xa3ffb22000, Total RAM: 0x3ffad6000 Memory hole size: 655360MB [00034000-f8a00080] page_structs=131072 node=0 entry=1280/0 [00034000-f8a000c0] page_structs=131072 node=0 entry=1281/0 [00034080-f8a00100] page_structs=131072 node=0 entry=1282/0 [00034080-f8a00140] page_structs=131072 node=0 entry=1283/0 [00034100-f8a00180] page_structs=131072 node=0 entry=1284/0 [00034100-f8a001c0] page_structs=131072 node=0 entry=1285/0 [00034180-f8a00200] page_structs=131072 node=0 entry=1286/0 [00034180-f8a00240] page_structs=131072 node=0 entry=1287/0 [00034200-f8a00280] page_structs=131072 node=0 entry=1288/0 [00034200-f8a002c0] page_structs=131072 node=0 entry=1289/0 [00034280-f8a00300] page_structs=131072 node=0 entry=1290/0 [00034280-f8a00340] page_structs=131072 node=0 entry=1291/0 [00034300-f8a00380] page_structs=131072 node=0 entry=1292/0 [00034300-f8a003c0] page_structs=131072 node=0 entry=1293/0 [00034380-f8a00400] page_structs=131072 node=0 entry=1294/0 [00034380-f8a00440] page_structs=131072 node=0 entry=1295/0 [00034400-f8a00480] page_structs=131072 node=0 entry=1296/0 [00034400-f8a004c0] page_structs=131072 node=0 entry=1297/0 [00034480-f8a00500] page_structs=131072 node=0 entry=1298/0 [00034480-f8a00540] page_structs=131072 node=0 entry=1299/0 [00034500-f8a00580] page_structs=131072 node=0 entry=1300/0 [00034500-f8a005c0] page_structs=131072 node=0 entry=1301/0 [00034580-f8a00600] page_structs=131072 node=0 entry=1302/0 [00034580-f8a00640] page_structs=131072 node=0 entry=1303/0 [00034600-f8a00680] page_structs=131072 node=0 entry=1304/0 [00034600-f8a006c0] page_structs=131072 node=0 entry=1305/0 [00034680-f8a00700] page_structs=131072 node=0 entry=1306/0 [00034680-f8a00740] page_structs=131072 node=0 entry=1307/0 [00034700-f8a00780] page_structs=131072 node=0 entry=1308/0 [00034700-f8a007c0] page_structs=131072 node=0 entry=1309/0 [00034780-f8a00800] page_structs=131072 node=0 entry=1310/0 [00034780-f8a00840] page_structs=131072 node=0 entry=1311/0 Zone PFN ranges: Normal 0x0500 - 0x051ffd91 Movable zone start PFN for each node early_node_map[4] active PFN ranges 0: 0x0500 - 0x051ff7ff 0: 0x051ff800 - 0x051ffd5c 0: 0x051ffd80 - 0x051ffd8f 0: 0x051ffd90 - 0x051ffd91 Booting Linux... Built 1 zonelists in Zone order, mobility grouping on. Total pages: 2080111 Kernel command line: PID hash table entries: 4096 (order: 12, 32768 bytes) Dentry cache hash table entries: 2097152 (order: 11, 16777216 bytes) Inode-cache hash table entries: 1048576 (order: 10, 8388608 bytes) Memory: 16610992k available (2488k kernel code, 936k data, 192k init) [f800,00a3ffb22000] NR_IRQS:255 clocksource: mult[64] shift[16] clockevent: mult[28f5c28] shift[32] -- Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg IWR; INF 368; 69120 Heidelberg; Tel: (06221)54-8236 Fax: -5224 Email: hermann.la...@iwr.uni-heidelberg.de -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Mon, Nov 23, 2009 at 12:24:46PM -0800, David Miller wrote: From: Josip Rodin j...@entuzijast.net Date: Sat, 31 Oct 2009 17:48:06 +0100 No idea, I got stuck there and reverted to .28. Then the machine started exhibiting some other issues so it was reverted to .26. :/ Sorry for dropping the ball on this one. As promised long ago, here is a 2.6.31.6 kernel built with you 2.6.31 config file. Let me know if it exhibits the bootup problem so we can diagnose further: http://vger.kernel.org/~davem/josip_test_2631_6.img Thanks! It works! Compiler issue? Here's the early portion of dmesg for the record: boot: LinuxDaveM Allocated 8 Megs of memory at 0x4000 for kernel Loaded kernel version 2.6.31 PROMLIB: Sun IEEE Boot Prom 'OBP 4.11.4 2003/07/23 08:04' PROMLIB: Root node compatible: Linux version 2.6.31.6 (da...@huronp11) (gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)) #2 SMP Mon Nov 23 12:18:05 PST 2009 console [earlyprom0] enabled ARCH: SUN4U Ethernet address: 00:03:ba:5a:53:a5 Kernel: Using 1 locked TLB entries for main kernel image. Remapping the kernel... done. OF stdout device is: /p...@1e,60/i...@7/ser...@0,3f8 PROM: Built device tree with 85818 bytes of memory. Top of RAM: 0x123fedc000, Total RAM: 0xffed4000 Memory hole size: 70656MB [0002-f840] page_structs=131072 node=0 entry=0/0 [0002-f880] page_structs=131072 node=0 entry=1/0 [00020400-f8c0] page_structs=131072 node=0 entry=16/0 [00020400-f8000100] page_structs=131072 node=0 entry=17/0 [00022000-f8000140] page_structs=131072 node=0 entry=128/0 [00022000-f8000180] page_structs=131072 node=0 entry=129/0 [00022400-f80001c0] page_structs=131072 node=0 entry=144/0 [00022400-f8000200] page_structs=131072 node=0 entry=145/0 Zone PFN ranges: Normal 0x - 0x0091ff6e Movable zone start PFN for each node early_node_map[7] active PFN ranges 0: 0x - 0x0002 0: 0x0010 - 0x0012 0: 0x0080 - 0x0082 0: 0x0090 - 0x0091f7ff 0: 0x0091f800 - 0x0091fef3 0: 0x0091fef5 - 0x0091ff60 0: 0x0091ff61 - 0x0091ff6e Booting Linux... Built 1 zonelists in Zone order, mobility grouping on. Total pages: 449387 Kernel command line: root=/dev/md1 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda2,/dev/sdb2 md=2,/dev/sda4,/dev/sdb4 md: Will configure md0 (super-block) from /dev/sda1,/dev/sdb1, below. md: Will configure md1 (super-block) from /dev/sda2,/dev/sdb2, below. md: Will configure md2 (super-block) from /dev/sda4,/dev/sdb4, below. PID hash table entries: 4096 (order: 12, 32768 bytes) Dentry cache hash table entries: 524288 (order: 9, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 8, 2097152 bytes) Memory: 4148904k available (2488k kernel code, 936k data, 192k init) [f800,00123fedc000] NR_IRQS:255 clocksource: mult[53] shift[16] clockevent: mult[3126e97] shift[32] Console: colour dummy device 80x25 console handover: boot [earlyprom0] - real [tty0] PROMLIB: Sun IEEE Boot Prom 'OBP 4.11.4 2003/07/23 08:04' PROMLIB: Root node compatible: Linux version 2.6.31.6 (da...@huronp11) (gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)) #2 SMP Mon Nov 23 12:18:05 PST 2009 console [earlyprom0] enabled ARCH: SUN4U Ethernet address: 00:03:ba:5a:53:a5 Kernel: Using 1 locked TLB entries for main kernel image. Remapping the kernel... done. OF stdout device is: /p...@1e,60/i...@7/ser...@0,3f8 PROM: Built device tree with 85818 bytes of memory. Top of RAM: 0x123fedc000, Total RAM: 0xffed4000 Memory hole size: 70656MB [0002-f840] page_structs=131072 node=0 entry=0/0 [0002-f880] page_structs=131072 node=0 entry=1/0 [00020400-f8c0] page_structs=131072 node=0 entry=16/0 [00020400-f8000100] page_structs=131072 node=0 entry=17/0 [00022000-f8000140] page_structs=131072 node=0 entry=128/0 [00022000-f8000180] page_structs=131072 node=0 entry=129/0 [00022400-f80001c0] page_structs=131072 node=0 entry=144/0 [00022400-f8000200] page_structs=131072 node=0 entry=145/0 Zone PFN ranges: Normal 0x - 0x0091ff6e Movable zone start PFN for each node early_node_map[7] active PFN ranges 0: 0x - 0x0002 0: 0x0010 - 0x0012 0: 0x0080 - 0x0082 0: 0x0090 - 0x0091f7ff 0: 0x0091f800 - 0x0091fef3 0: 0x0091fef5 - 0x0091ff60 0: 0x0091ff61 - 0x0091ff6e Booting Linux... Built 1 zonelists in Zone order, mobility grouping on. Total pages: 449387 Kernel command line: root=/dev/md1 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda2,/dev/sdb2 md=2,/dev/sda4,/dev/sdb4 md: Will configure md0 (super-block) from /dev/sda1,/dev/sdb1, below. md: Will configure md1 (super-block) from /dev/sda2,/dev/sdb2, below. md: Will configure md2 (super-block) from
Re: Sparc release requalification
On Mon, Nov 23, 2009 at 02:32:04PM -0800, David Miller wrote: From: Josip Rodin j...@entuzijast.net Date: Mon, 23 Nov 2009 23:27:34 +0100 On Mon, Nov 23, 2009 at 12:24:46PM -0800, David Miller wrote: From: Josip Rodin j...@entuzijast.net Date: Sat, 31 Oct 2009 17:48:06 +0100 No idea, I got stuck there and reverted to .28. Then the machine started exhibiting some other issues so it was reverted to .26. :/ Sorry for dropping the ball on this one. As promised long ago, here is a 2.6.31.6 kernel built with you 2.6.31 config file. Let me know if it exhibits the bootup problem so we can diagnose further: http://vger.kernel.org/~davem/josip_test_2631_6.img Thanks! It works! Compiler issue? Something like that. It could also just be compiled differently by your gcc and expose some race or bug. OK. Yours has gcc 4.2.4, and our ones have gcc 4.3.2 (that we shipped as stable :) I also just tried a newer packaged image, and it has the same issue. It comes from the linux-image-2.6.30-bpo.2-sparc64-smp package, which you can get from: http://www.backports.org/debian/pool/main/l/linux-2.6/linux-image-2.6.30-bpo.2-sparc64-smp_2.6.30-8~bpo50+1_sparc.deb To extract, use: dpkg-deb -x linux-image-2.6.30-bpo.2-sparc64-smp_2.6.30-8~bpo50+1_sparc.deb newdir And then you have newdir/boot/vmlinuz-2.6.30-bpo.2-sparc64-smp etc -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Thu, Sep 24, 2009 at 12:03:37AM +0200, Josip Rodin wrote: On Fri, Sep 18, 2009 at 10:19:39AM -0700, David Miller wrote: I built my kernel using v2.6.30.x -stable FWIW. I'll try straight 2.6.31 with your config. I wonder if we're in the territory of some compiler issue. I'm guessing that compile is finished by now :) can you please post the link for me to try and boot? I didn't get around to it, I have to run off now to LinuxCon and LinuxPlumbers so all of this will have to wait 2 weeks. Sorry. FWIW I've since compiled and tested latest stable .30, .29 and .28, just to make sure I'm not hitting a heisenbug, but the symptoms are unchanged for .30 and .29, while .28 works. The compiler is the Debian 'stable' sparc gcc, nothing fancy there. Josip, did you manage to figure out what's going on here? Did we conclude it is a toolchain issue? Cheers. -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Sat, Oct 31, 2009 at 03:08:47PM +, Jurij Smakov wrote: I built my kernel using v2.6.30.x -stable FWIW. I'll try straight 2.6.31 with your config. I wonder if we're in the territory of some compiler issue. I'm guessing that compile is finished by now :) can you please post the link for me to try and boot? I didn't get around to it, I have to run off now to LinuxCon and LinuxPlumbers so all of this will have to wait 2 weeks. Sorry. FWIW I've since compiled and tested latest stable .30, .29 and .28, just to make sure I'm not hitting a heisenbug, but the symptoms are unchanged for .30 and .29, while .28 works. The compiler is the Debian 'stable' sparc gcc, nothing fancy there. Josip, did you manage to figure out what's going on here? Did we conclude it is a toolchain issue? No idea, I got stuck there and reverted to .28. Then the machine started exhibiting some other issues so it was reverted to .26. :/ -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Fri, Sep 18, 2009 at 10:19:39AM -0700, David Miller wrote: I built my kernel using v2.6.30.x -stable FWIW. I'll try straight 2.6.31 with your config. I wonder if we're in the territory of some compiler issue. I'm guessing that compile is finished by now :) can you please post the link for me to try and boot? I didn't get around to it, I have to run off now to LinuxCon and LinuxPlumbers so all of this will have to wait 2 weeks. Sorry. FWIW I've since compiled and tested latest stable .30, .29 and .28, just to make sure I'm not hitting a heisenbug, but the symptoms are unchanged for .30 and .29, while .28 works. The compiler is the Debian 'stable' sparc gcc, nothing fancy there. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
Matthias Klose a écrit : On 20.08.2009 16:52, Aurelien Jarno wrote: Bastian Blank a écrit : On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote: I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - define a new sparc64 port, and bootstrap this one using the 32bit port. This is rather easy. I already did a s390x bootstrap using this method. If we are not sure that sparc and s390 (ie 32-bit versions) would be suitable for squeeze, this is almost sure they won't be suitable for squeeze+1. Isn't it the right moment to start a sparc64 and an s390x port, and if they are ready for squeeze release with them? Almost whatever upgrade solution you offer will require to have at least one release with both old and new architecture (like we did for arm - armel). Given that we already have sparc and s390 in the archive and that we also already have 64-bit ports, I don't expect any major problem for those new ports. Also given quite fast hardware exists for those architectures, it can probably be done relatively quickly. this seems to be the way to go, but port maintainers seem to lack enthusiasm or resources. I'm willing to help, if somebody commits to these ports. I'm willing to help too if such a project is started. Any other volunteer? -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On 06.09.2009 16:49, Jurij Smakov wrote: On Thu, Aug 20, 2009 at 12:20:01PM +0200, Matthias Klose wrote: On 19.08.2009 16:33, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:55:24PM +0200, Matthias Klose wrote: On 19.08.2009 13:42, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote: I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - have an inplace-transition building required library packages for an upgrade as biarch packages and continue to use the current sparc name. This would mean that many packages needs to be modified. Is it really worth the work needed if we consider the availability of multiarch in the next time? you'll end up modifying a different set of packages for the new architecture name in control and rules files. I don't know if this is less or more work. If I understand this correctly, this would need the modification off all library packages to implement biarch semantic. No, just a subset that an update from 32-64bit userland does work. Again, I don't know how big this subset will be. Matthias, can you please make a definite statement on whether you, as a toolchain maintainer, are willing to support the existing 32-bit userland with a 64-bit kernel, or you consider a transition to 64-bit userland a necessary condition for sparc to be released with squeeze. This will be an important factor for the release team to determine what is going the port is currently using 4.3 as the default, I do plan to make 4.4 the default unless port maintainers object [1]. Ubuntu karmic already uses 4.4 as the default, but as a community port sparc doesn't get the same attention as other ports. Please see [2] for current problems with sparc. I do not plan to invest significant time in fixing build issues on sparc for squeeze. I do commit to prepare binutils and gcc-4.4 for a sparc64 port if this should happen for squeeze. Matthias [1] http://lists.debian.org/debian-release/2009/09/msg00239.html [2] http://qa.ubuntuwire.org/ftbfs/ -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On 20.08.2009 16:52, Aurelien Jarno wrote: Bastian Blank a écrit : On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote: I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - define a new sparc64 port, and bootstrap this one using the 32bit port. This is rather easy. I already did a s390x bootstrap using this method. If we are not sure that sparc and s390 (ie 32-bit versions) would be suitable for squeeze, this is almost sure they won't be suitable for squeeze+1. Isn't it the right moment to start a sparc64 and an s390x port, and if they are ready for squeeze release with them? Almost whatever upgrade solution you offer will require to have at least one release with both old and new architecture (like we did for arm - armel). Given that we already have sparc and s390 in the archive and that we also already have 64-bit ports, I don't expect any major problem for those new ports. Also given quite fast hardware exists for those architectures, it can probably be done relatively quickly. this seems to be the way to go, but port maintainers seem to lack enthusiasm or resources. I'm willing to help, if somebody commits to these ports. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Wed, Sep 16, 2009 at 04:49:34PM -0700, David Miller wrote: I built my kernel using v2.6.30.x -stable FWIW. I'll try straight 2.6.31 with your config. I wonder if we're in the territory of some compiler issue. I'm guessing that compile is finished by now :) can you please post the link for me to try and boot? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
From: Josip Rodin j...@entuzijast.net Date: Fri, 18 Sep 2009 15:24:51 +0200 On Wed, Sep 16, 2009 at 04:49:34PM -0700, David Miller wrote: I built my kernel using v2.6.30.x -stable FWIW. I'll try straight 2.6.31 with your config. I wonder if we're in the territory of some compiler issue. I'm guessing that compile is finished by now :) can you please post the link for me to try and boot? I didn't get around to it, I have to run off now to LinuxCon and LinuxPlumbers so all of this will have to wait 2 weeks. Sorry. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Tue, Sep 15, 2009 at 12:05:30PM +0200, Sébastien Bernard wrote: I was able to reproduce the hang with your originally posted config. It only triggers when CONFIG_PROM_CONSOLE is enabled Very good news. I had a lot of trouble because of this. I had to disable it for initcall_debug to work, but then, any kernel patched or not was working. I thought I messed up between patches and built kernels. I realize now that I had the explanation under my nose. Duh I had just recompiled and booted my SMP kernel without the dreaded PROM_CONSOLE, and yet the machine got stuck in the same place in the NMI code. I then removed initcall_debug, and it still doesn't work. What am I missing?! The .config diff between the working UP kernel and this one is: --- /boot/config.old2009-09-14 12:08:04.0 + +++ /boot/config2009-09-16 07:44:16.0 + @@ -4 +4 @@ -# Mon Sep 14 11:47:09 2009 +# Tue Sep 15 09:59:03 2009 @@ -35 +35 @@ -CONFIG_BROKEN_ON_SMP=y +CONFIG_LOCK_KERNEL=y @@ -113,0 +114 @@ +CONFIG_USE_GENERIC_SMP_HELPERS=y @@ -129,0 +131 @@ +CONFIG_STOP_MACHINE=y @@ -152 +154,2 @@ -# CONFIG_SMP is not set +CONFIG_SMP=y +CONFIG_NR_CPUS=32 @@ -163,0 +167 @@ +CONFIG_SPARC64_SMP=y @@ -166,0 +171 @@ +# CONFIG_HOTPLUG_CPU is not set @@ -172,0 +178 @@ +# CONFIG_NUMA is not set @@ -193,0 +200,2 @@ +CONFIG_SCHED_SMT=y +CONFIG_SCHED_MC=y @@ -1141 +1149 @@ -CONFIG_PROM_CONSOLE=y +# CONFIG_PROM_CONSOLE is not set -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Tue, Sep 15, 2009 at 08:38:22PM +0100, Jurij Smakov wrote: If the PROM console driver still has some utility, maybe the boot option is the way to go... does it? Does anyone still manufacture new machines with new and strange console types that we don't support? :) The PROM console driver has no relevance today at all. It should simply never be used. OK, cool, please remove it, and also please propagate that to the stable branches so we don't miss anyone who's not on the bleeding edge. Please feel free to follow up on http://bugs.debian.org/525958 which I've filed in April to have the CONFIG_PROM_CONSOLE removed. Yeah, definitely, Cc:ed. Dave has in the meantime killed it completely in his stable tree: http://git.kernel.org/?p=linux/kernel/git/davem/sparc-2.6.git;a=commit;h=09d3f3f0e02c8a900d076c302c5c02227f33572d There's another commit that takes it out of the defconfigs completely - it was already unset there for a while now. So it's pretty much official now (well, Linus still has to take it in, but that should be a formality). -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
From: Josip Rodin j...@entuzijast.net Date: Wed, 16 Sep 2009 09:57:22 +0200 On Tue, Sep 15, 2009 at 12:05:30PM +0200, Sébastien Bernard wrote: I was able to reproduce the hang with your originally posted config. It only triggers when CONFIG_PROM_CONSOLE is enabled Very good news. I had a lot of trouble because of this. I had to disable it for initcall_debug to work, but then, any kernel patched or not was working. I thought I messed up between patches and built kernels. I realize now that I had the explanation under my nose. Duh I had just recompiled and booted my SMP kernel without the dreaded PROM_CONSOLE, and yet the machine got stuck in the same place in the NMI code. I then removed initcall_debug, and it still doesn't work. What am I missing?! The .config diff between the working UP kernel and this one is: I put up the kernel image I booted with your config (sans PROM_CONSOLE) at: http://vger.kernel.org/~davem/vmlinux-debug give it a try. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
David Miller a écrit : I put up the kernel image I booted with your config (sans PROM_CONSOLE) at: http://vger.kernel.org/~davem/vmlinux-debug give it a try. -- To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Works for me ok. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Wed, Sep 16, 2009 at 01:14:35AM -0700, David Miller wrote: I thought I messed up between patches and built kernels. I realize now that I had the explanation under my nose. Duh I had just recompiled and booted my SMP kernel without the dreaded PROM_CONSOLE, and yet the machine got stuck in the same place in the NMI code. I then removed initcall_debug, and it still doesn't work. What am I missing?! The .config diff between the working UP kernel and this one is: I put up the kernel image I booted with your config (sans PROM_CONSOLE) at: http://vger.kernel.org/~davem/vmlinux-debug give it a try. Yours works fine... I've reverted all the interim patches and rebuilt mine, and it still won't boot, hanging in the same place again. I don't get it. I'm attaching the exact .config used in my last attempt, just in case. diff says PROM_CONSOLE is the only change. I'll be going over your image's config (extracted from /proc/config.gz). -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Wed, Sep 16, 2009 at 10:03:46AM +0200, Josip Rodin wrote: On Tue, Sep 15, 2009 at 08:38:22PM +0100, Jurij Smakov wrote: If the PROM console driver still has some utility, maybe the boot option is the way to go... does it? Does anyone still manufacture new machines with new and strange console types that we don't support? :) The PROM console driver has no relevance today at all. It should simply never be used. OK, cool, please remove it, and also please propagate that to the stable branches so we don't miss anyone who's not on the bleeding edge. Please feel free to follow up on http://bugs.debian.org/525958 which I've filed in April to have the CONFIG_PROM_CONSOLE removed. Yeah, definitely, Cc:ed. Dave has in the meantime killed it completely in his stable tree: http://git.kernel.org/?p=linux/kernel/git/davem/sparc-2.6.git;a=commit;h=09d3f3f0e02c8a900d076c302c5c02227f33572d There's another commit that takes it out of the defconfigs completely - it was already unset there for a while now. So it's pretty much official now (well, Linus still has to take it in, but that should be a formality). Disabled in trunk for 2.6.31. Could you test a Lenny image with CONSOLE_PROM_CONSOLE disabled to verify there are no regressions? Cheers, Moritz -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
From: Josip Rodin j...@entuzijast.net Date: Wed, 16 Sep 2009 14:49:00 +0200 I'm attaching the exact .config used in my last attempt, just in case. Where is that attachment? :-) I want to try it again here myself as a double check. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Wed, Sep 16, 2009 at 03:48:18PM -0700, David Miller wrote: From: Josip Rodin j...@entuzijast.net Date: Wed, 16 Sep 2009 14:49:00 +0200 I'm attaching the exact .config used in my last attempt, just in case. Where is that attachment? :-) I want to try it again here myself as a double check. Oh sorry, standard attachment error :) Now it's attached. -- 2. That which causes joy or happiness. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.31 # Tue Sep 15 09:59:03 2009 # CONFIG_64BIT=y CONFIG_SPARC=y # CONFIG_SPARC32 is not set CONFIG_SPARC64=y CONFIG_ARCH_DEFCONFIG=arch/sparc/configs/sparc64_defconfig CONFIG_BITS=64 CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_IOMMU_HELPER=y CONFIG_QUICKLIST=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_AUDIT_ARCH=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_HAVE_DYNAMIC_PER_CPU_AREA=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_MMU=y CONFIG_ARCH_NO_VIRT_TO_BUS=y CONFIG_OF=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_CONSTRUCTORS=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # # RCU Subsystem # CONFIG_CLASSIC_RCU=y # CONFIG_TREE_RCU is not set # CONFIG_PREEMPT_RCU is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_PREEMPT_RCU_TRACE is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=15 # CONFIG_GROUP_SCHED is not set # CONFIG_CGROUPS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_RELAY=y CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_NET_NS is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y # # Performance Counters # CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y # CONFIG_STRIP_ASM_SYMS is not set CONFIG_COMPAT_BRK=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set # CONFIG_PROFILING is not set # CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_SYSCALL_WRAPPERS=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_USE_GENERIC_SMP_HELPERS=y # # GCOV-based kernel profiling # # CONFIG_GCOV_KERNEL is not set # CONFIG_SLOW_WORK is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # CONFIG_FREEZER is not set # # Processor type and features # CONFIG_SMP=y CONFIG_NR_CPUS=32 # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 # CONFIG_SCHED_HRTICK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_SPARC64_SMP=y CONFIG_SPARC64_PAGE_SIZE_8KB=y # CONFIG_SPARC64_PAGE_SIZE_64KB is not set CONFIG_SECCOMP=y # CONFIG_HOTPLUG_CPU is not set CONFIG_GENERIC_HARDIRQS=y # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_CPU_FREQ is not set CONFIG_US3_MC=y # CONFIG_NUMA is not set CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_DEFAULT=y CONFIG_SELECT_MEMORY_MODEL=y # CONFIG_FLATMEM_MANUAL is not set # CONFIG_DISCONTIGMEM_MANUAL is not set CONFIG_SPARSEMEM_MANUAL=y CONFIG_SPARSEMEM=y CONFIG_HAVE_MEMORY_PRESENT=y CONFIG_SPARSEMEM_EXTREME=y CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y CONFIG_SPARSEMEM_VMEMMAP=y CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_PHYS_ADDR_T_64BIT=y CONFIG_ZONE_DMA_FLAG=0 CONFIG_NR_QUICK=1
Re: Sparc release requalification
From: Josip Rodin j...@entuzijast.net Date: Thu, 17 Sep 2009 01:29:37 +0200 On Wed, Sep 16, 2009 at 03:48:18PM -0700, David Miller wrote: From: Josip Rodin j...@entuzijast.net Date: Wed, 16 Sep 2009 14:49:00 +0200 I'm attaching the exact .config used in my last attempt, just in case. Where is that attachment? :-) I want to try it again here myself as a double check. Oh sorry, standard attachment error :) Now it's attached. I built my kernel using v2.6.30.x -stable FWIW. I'll try straight 2.6.31 with your config. I wonder if we're in the territory of some compiler issue. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
From: Josip Rodin j...@entuzijast.net Date: Thu, 17 Sep 2009 01:29:37 +0200 On Wed, Sep 16, 2009 at 03:48:18PM -0700, David Miller wrote: From: Josip Rodin j...@entuzijast.net Date: Wed, 16 Sep 2009 14:49:00 +0200 I'm attaching the exact .config used in my last attempt, just in case. Where is that attachment? :-) I want to try it again here myself as a double check. Oh sorry, standard attachment error :) Now it's attached. BTW, while we're on the topic of configurations, dists should use a CONFIG_NR_CPUS value of at least 256 as that's the highest cpu count out there on real sparc64 systems (Bartoka 4 socket Niagara-T2+, 64 cpus per socket, 4 * 64 == 256). -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
From: Josip Rodin j...@entuzijast.net
Date: Mon, 14 Sep 2009 14:36:48 +0200
It seems to work just fine without SMP.
This is start_watchdog(), writing picl_value(nmi_hz)=-17214228922368000 into
PIC...
This is nmi_init(), entering check_nmi_watchdog()...
Testing NMI watchdog ... OK.
[...]
Ok, great.
This is all so strange because I have the exact same cpu types
and cpu numbers as these V240's that see the problems.
Ok, next test. Rebuild SMP and try the following two patches,
one at a time.
1) The first patch disables the idle spin loop used to help
ensure the cpu is actually executing instructions during
the NMI test.
This might be it because this doesn't actually even get used
in UP builds.
2) The second patch forces the NMI interrupt handler to only
end up executing once. The NMI test will fail if this
test fixes things, and it's to see if somehow the
rescheduling of the NMI event is to blame.
Thanks!
diff --git a/arch/sparc/kernel/nmi.c b/arch/sparc/kernel/nmi.c
index 2c0cc72..21ec244 100644
--- a/arch/sparc/kernel/nmi.c
+++ b/arch/sparc/kernel/nmi.c
@@ -164,7 +164,8 @@ static int __init check_nmi_watchdog(void)
printk(KERN_INFO Testing NMI watchdog ... );
- smp_call_function(nmi_cpu_busy, (void *)endflag, 0);
+ if (0)
+ smp_call_function(nmi_cpu_busy, (void *)endflag, 0);
for_each_possible_cpu(cpu)
prev_nmi_count[cpu] = get_nmi_count(cpu);
diff --git a/arch/sparc/kernel/nmi.c b/arch/sparc/kernel/nmi.c
index 2c0cc72..b985ae8 100644
--- a/arch/sparc/kernel/nmi.c
+++ b/arch/sparc/kernel/nmi.c
@@ -110,10 +110,12 @@ notrace __kprobes void perfctr_irq(int irq, struct pt_regs *regs)
__get_cpu_var(last_irq_sum) = sum;
local_set(__get_cpu_var(alert_counter), 0);
}
+#if 0
if (nmi_usable) {
write_pic(picl_value(nmi_hz));
pcr_ops-write(pcr_enable);
}
+#endif
}
static inline unsigned int get_nmi_count(int cpu)
Re: Sparc release requalification
From: Josip Rodin j...@entuzijast.net Date: Mon, 14 Sep 2009 14:40:22 +0200 On Mon, Sep 14, 2009 at 02:36:48PM +0200, Josip Rodin wrote: 2) Try a UP kernel build, does it work even with all of the NMI bits enabled on this machine? Will try and report shortly. It seems to work just fine without SMP. Just in case it might matter: I was able to reproduce the hang with your originally posted config. It only triggers when CONFIG_PROM_CONSOLE is enabled, I keep telling people to turn it off. Nobody should be using it, it either breaks things or it slows the console down considerably. That's it, I'm completely removing that driver from the tree this merge window, so you guys can't mess it up any more even if you want to :-) -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Tue, Sep 15, 2009 at 02:11:24AM -0700, David Miller wrote: I was able to reproduce the hang with your originally posted config. It only triggers when CONFIG_PROM_CONSOLE is enabled, I keep telling people to turn it off. Nobody should be using it, it either breaks things or it slows the console down considerably. That's it, I'm completely removing that driver from the tree this merge window, so you guys can't mess it up any more even if you want to :-) Oh! Well, that's good. I googled for it now and found in some Ubuntu kernel changelog that Fabio did it this way: linux-source-2.6.17 (2.6.17-10.26) edgy; urgency=low * make promcon driver init a boot option: - fix Niagara cpu soft lockups. (Closes Ubuntu: #61821) The generic PROM_CONSOLE driver is just too slow and blocks IRQ during normal output. Ideally the PROM_CONSOLE should be used only if we fail to find the correct driver for a certain hardware. In reality when built in it will be always used as default. With this workaround, we init the driver only on specific requests. The pro is that all machines that have a working console driver will notice a speed up at boot. The cons is that machines for which we have no driver will need to wait for one or boot with forcepromconsole boot option. -- Fabio M. Di Nitto email address hidden Mon, 02 Oct 2006 06:48:54 +0200 If the PROM console driver still has some utility, maybe the boot option is the way to go... does it? Does anyone still manufacture new machines with new and strange console types that we don't support? :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Tue, Sep 15, 2009 at 03:01:29AM -0700, David Miller wrote: From: Josip Rodin j...@entuzijast.net Date: Tue, 15 Sep 2009 11:58:33 +0200 If the PROM console driver still has some utility, maybe the boot option is the way to go... does it? Does anyone still manufacture new machines with new and strange console types that we don't support? :) The PROM console driver has no relevance today at all. It should simply never be used. OK, cool, please remove it, and also please propagate that to the stable branches so we don't miss anyone who's not on the bleeding edge. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
David Miller a écrit : From: Josip Rodin j...@entuzijast.net Date: Mon, 14 Sep 2009 14:40:22 +0200 On Mon, Sep 14, 2009 at 02:36:48PM +0200, Josip Rodin wrote: 2) Try a UP kernel build, does it work even with all of the NMI bits enabled on this machine? Will try and report shortly. It seems to work just fine without SMP. Just in case it might matter: I was able to reproduce the hang with your originally posted config. It only triggers when CONFIG_PROM_CONSOLE is enabled, I keep telling people to turn it off. Nobody should be using it, it either breaks things or it slows the console down considerably. That's it, I'm completely removing that driver from the tree this merge window, so you guys can't mess it up any more even if you want to :-) Very good news. I had a lot of trouble because of this. I had to disable it for initcall_debug to work, but then, any kernel patched or not was working. I thought I messed up between patches and built kernels. I realize now that I had the explanation under my nose. Duh Seb -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
From: Josip Rodin j...@entuzijast.net Date: Tue, 15 Sep 2009 11:58:33 +0200 If the PROM console driver still has some utility, maybe the boot option is the way to go... does it? Does anyone still manufacture new machines with new and strange console types that we don't support? :) The PROM console driver has no relevance today at all. It should simply never be used. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Tue, Sep 15, 2009 at 12:03:06PM +0200, Josip Rodin wrote: On Tue, Sep 15, 2009 at 03:01:29AM -0700, David Miller wrote: From: Josip Rodin j...@entuzijast.net Date: Tue, 15 Sep 2009 11:58:33 +0200 If the PROM console driver still has some utility, maybe the boot option is the way to go... does it? Does anyone still manufacture new machines with new and strange console types that we don't support? :) The PROM console driver has no relevance today at all. It should simply never be used. OK, cool, please remove it, and also please propagate that to the stable branches so we don't miss anyone who's not on the bleeding edge. Please feel free to follow up on http://bugs.debian.org/525958 which I've filed in April to have the CONFIG_PROM_CONSOLE removed. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
From: Josip Rodin j...@entuzijast.net Date: Sat, 12 Sep 2009 13:05:59 +0200 The 2.6.31 release. (Actually stable 2.6.31.y git but that's currently the same.) Ok: 1) Give me the output of /proc/cpuinfo 2) Try a UP kernel build, does it work even with all of the NMI bits enabled on this machine? Thanks. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Mon, Sep 14, 2009 at 03:24:56AM -0700, David Miller wrote: 1) Give me the output of /proc/cpuinfo cpu : TI UltraSparc IIIi (Jalapeno) fpu : UltraSparc IIIi integrated FPU pmu : ultra3i prom: OBP 4.11.4 2003/07/23 08:04 type: sun4u ncpus probed: 2 ncpus active: 2 D$ parity tl1 : 0 I$ parity tl1 : 0 Cpu0ClkTck : 3bb94e80 Cpu1ClkTck : 3bb94e80 MMU Type: Cheetah+ State: CPU0: online CPU1: online 2) Try a UP kernel build, does it work even with all of the NMI bits enabled on this machine? Will try and report shortly. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Mon, Sep 14, 2009 at 01:46:43PM +0200, Josip Rodin wrote: On Mon, Sep 14, 2009 at 03:24:56AM -0700, David Miller wrote: 1) Give me the output of /proc/cpuinfo cpu : TI UltraSparc IIIi (Jalapeno) fpu : UltraSparc IIIi integrated FPU pmu : ultra3i prom: OBP 4.11.4 2003/07/23 08:04 type: sun4u ncpus probed: 2 ncpus active: 2 D$ parity tl1 : 0 I$ parity tl1 : 0 Cpu0ClkTck : 3bb94e80 Cpu1ClkTck : 3bb94e80 MMU Type: Cheetah+ State: CPU0: online CPU1: online 2) Try a UP kernel build, does it work even with all of the NMI bits enabled on this machine? Will try and report shortly. It seems to work just fine without SMP. This is start_watchdog(), writing picl_value(nmi_hz)=-17214228922368000 into PIC... This is nmi_init(), entering check_nmi_watchdog()... Testing NMI watchdog ... OK. [...] -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Mon, Sep 14, 2009 at 02:36:48PM +0200, Josip Rodin wrote: 2) Try a UP kernel build, does it work even with all of the NMI bits enabled on this machine? Will try and report shortly. It seems to work just fine without SMP. Just in case it might matter: --- /boot/config-2.6.31.old 2009-09-11 23:10:03.0 + +++ /boot/config-2.6.31 2009-09-14 12:08:04.0 + @@ -4 +4 @@ -# Fri Sep 11 18:23:35 2009 +# Mon Sep 14 11:47:09 2009 @@ -35 +35 @@ -CONFIG_LOCK_KERNEL=y +CONFIG_BROKEN_ON_SMP=y @@ -114 +113,0 @@ -CONFIG_USE_GENERIC_SMP_HELPERS=y @@ -131 +129,0 @@ -CONFIG_STOP_MACHINE=y @@ -154,2 +152 @@ -CONFIG_SMP=y -CONFIG_NR_CPUS=32 +# CONFIG_SMP is not set @@ -167 +163,0 @@ -CONFIG_SPARC64_SMP=y @@ -171 +166,0 @@ -# CONFIG_HOTPLUG_CPU is not set @@ -178 +172,0 @@ -# CONFIG_NUMA is not set @@ -200,2 +193,0 @@ -CONFIG_SCHED_SMT=y -CONFIG_SCHED_MC=y -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
David Miller a écrit : 1) Give me the output of /proc/cpuinfo 2) Try a UP kernel build, does it work even with all of the NMI bits enabled on this machine? Thanks. Here's the cpuinfo from a 2.6.24 UP kernel : cpu : TI UltraSparc IIIi (Jalapeno) fpu : UltraSparc IIIi integrated FPU prom: OBP 4.22.33 2007/06/18 12:45 type: sun4u ncpus probed: 2 ncpus active: 1 D$ parity tl1 : 0 I$ parity tl1 : 0 Cpu0ClkTck : 4c4b4000 MMU Type: Cheetah+ There is no hang with UP kernel. Seb -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
From: Josip Rodin j...@entuzijast.net Date: Sat, 12 Sep 2009 13:05:59 +0200 On Sat, Sep 12, 2009 at 02:59:43AM -0700, David Miller wrote: From: Josip Rodin j...@entuzijast.net Date: Sat, 12 Sep 2009 11:49:54 +0200 I see this %pcr handling has been in debugging code (oprofile, performance counters) for some time before it moved into the NMI handler, so I'm guessing it didn't get enough testing because fewer people have the debugging features enabled. I would recommend disabling it for now in the stable releases until this grave regression is resolved. Remind me what kernel you're trying now? The 2.6.31 release. (Actually stable 2.6.31.y git but that's currently the same.) Ok, I'm motivated to simply fix this and it seems you are too. I'll come up with a game plane to kill this for good, because I suspect whatever is causing this is actually unrelated to the NMI feature and is actually something more funamental on SMP on these UltraSPARC-III+ machines. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Fri, Sep 11, 2009 at 05:18:18PM -0700, David Miller wrote: Could this consistency be of any significance, maybe the printk functions are somehow problematic... so I fiddled with them some more, but it looks more like they just waste time until something kicks in and somehow kills the kernel without a trace. That doesn't sound like perfctr_irq() and die_nmi(), but then I don't really any idea how exactly all that works :) You can't put debugging print statements in the NMI irq handlers like perfctr_irq(), that will almost always cause a lockup or crash. Nah, didn't even try that - I saw that the existing printk() in there doesn't even show up, despite obvious tries to make it so. In case it matters, this is a tlb_type=cheetah_plus machine. I see this %pcr handling has been in debugging code (oprofile, performance counters) for some time before it moved into the NMI handler, so I'm guessing it didn't get enough testing because fewer people have the debugging features enabled. I would recommend disabling it for now in the stable releases until this grave regression is resolved. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
From: Josip Rodin j...@entuzijast.net Date: Sat, 12 Sep 2009 11:49:54 +0200 I see this %pcr handling has been in debugging code (oprofile, performance counters) for some time before it moved into the NMI handler, so I'm guessing it didn't get enough testing because fewer people have the debugging features enabled. I would recommend disabling it for now in the stable releases until this grave regression is resolved. Remind me what kernel you're trying now? -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Sat, Sep 12, 2009 at 02:59:43AM -0700, David Miller wrote: From: Josip Rodin j...@entuzijast.net Date: Sat, 12 Sep 2009 11:49:54 +0200 I see this %pcr handling has been in debugging code (oprofile, performance counters) for some time before it moved into the NMI handler, so I'm guessing it didn't get enough testing because fewer people have the debugging features enabled. I would recommend disabling it for now in the stable releases until this grave regression is resolved. Remind me what kernel you're trying now? The 2.6.31 release. (Actually stable 2.6.31.y git but that's currently the same.) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Sun, Sep 06, 2009 at 11:21:42PM +0200, Sébastien Bernard wrote: the sid kernels are not booting on my machine (SunBlade 1000), and I have an independent confirmation from someone with a similar machine that they are experiencing similar problems - I'm going to file a bug for that if the situation does not improve with the next kernel upload. [ 61.022918] CPU 1: synchronized TICK with master CPU (last diff 0 cycles, maxerr 5 cycles) [ 61.022933] Brought up 2 CPUs [ 61.024050] net_namespace: 1936 bytes [ 61.200137] regulator: core version 0.5 [ 61.245754] NET: Registered protocol family 16 [ 61 It just hangs right there, with the last string only partially displayed and cursor blinking right after '61'. I think you hit the same bug as I do on my V240 (same hardware I think). I just tried to upgrade from 2.6.26/2.6.28.7 to 2.6.31 on one of our V240s and I seem to have reproduced this pretty peculiar problem: PROMLIB: Sun IEEE Boot Prom 'OBP 4.11.4 2003/07/23 08:04' PROMLIB: Root node compatible: Linux version 2.6.31 (j...@schroeder) (gcc version 4.3.2 (Debian 4.3.2-1.1) ) #1 SMP Fri Sep 11 18:39:54 UTC 2009 console [earlyprom0] enabled ARCH: SUN4U Ethernet address: 00:03:ba:5a:53:a5 Kernel: Using 1 locked TLB entries for main kernel image. Remapping the kernel... done. OF stdout device is: /p...@1e,60/i...@7/ser...@0,3f8 PROM: Built device tree with 85818 bytes of memory. Top of RAM: 0x123fedc000, Total RAM: 0xffed4000 Memory hole size: 70656MB [0002-f840] page_structs=131072 node=0 entry=0/0 [0002-f880] page_structs=131072 node=0 entry=1/0 [00020400-f8c0] page_structs=131072 node=0 entry=16/0 [00020400-f8000100] page_structs=131072 node=0 entry=17/0 [00022000-f8000140] page_structs=131072 node=0 entry=128/0 [00022000-f8000180] page_structs=131072 node=0 entry=129/0 [00022400-f80001c0] page_structs=131072 node=0 entry=144/0 [00022400-f8000200] page_structs=131072 node=0 entry=145/0 Zone PFN ranges: Normal 0x - 0x0091ff6e Movable zone start PFN for each node early_node_map[7] active PFN ranges 0: 0x - 0x0002 0: 0x0010 - 0x0012 0: 0x0080 - 0x0082 0: 0x0090 - 0x0091f7ff 0: 0x0091f800 - 0x0091fef3 0: 0x0091fef5 - 0x0091ff60 0: 0x0091ff61 - 0x0091ff6e Booting Linux... Built 1 zonelists in Zone order, mobility grouping on. Total pages: 449387 Kernel command line: root=/dev/md1 ro rootdelay=20 console=ttyS0,9600n1 PID hash table entries: 4096 (order: 12, 32768 bytes) Dentry cache hash table entries: 524288 (order: 9, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 8, 2097152 bytes) Memory: 4148904k available (2520k kernel code, 928k data, 200k init) [f800,00123fedc000] NR_IRQS:255 clocksource: mult[53] shift[16] clockevent: mult[3126e97] shift[32] Console: colour dummy device 80x25 Calibrating delay using timer specific routine.. 24.01 BogoMIPS (lpj=48029) Mount-cache hash table entries: 512 CPU 0: synchronized TICK with master CPU (last diff -1 cycles, maxerr 7 cycles) Brought up 2 CPUs NET: Registered protocol family 16 Test It just froze right there. This V240 doesn't actually include any qla2xxx hardware, so the 5-30 second NMI patch which is included in 2.6.31 doesn't sound to me like it would ever affect it anyway... I noticed in other thread that initcall_debug=1 ignore_loglevel information may be useful, so here goes: PROMLIB: Sun IEEE Boot Prom 'OBP 4.11.4 2003/07/23 08:04' PROMLIB: Root node compatible: Linux version 2.6.31 (j...@schroeder) (gcc version 4.3.2 (Debian 4.3.2-1.1) ) #1 SMP Fri Sep 11 18:39:54 UTC 2009 debug: ignoring loglevel setting. console [earlyprom0] enabled ARCH: SUN4U Ethernet address: 00:03:ba:5a:53:a5 Kernel: Using 1 locked TLB entries for main kernel image. Remapping the kernel... done. OF stdout device is: /p...@1e,60/i...@7/ser...@0,3f8 PROM: Built device tree with 85818 bytes of memory. Top of RAM: 0x123fedc000, Total RAM: 0xffed4000 Memory hole size: 70656MB [0002-f840] page_structs=131072 node=0 entry=0/0 [0002-f880] page_structs=131072 node=0 entry=1/0 [00020400-f8c0] page_structs=131072 node=0 entry=16/0 [00020400-f8000100] page_structs=131072 node=0 entry=17/0 [00022000-f8000140] page_structs=131072 node=0 entry=128/0 [00022000-f8000180] page_structs=131072 node=0 entry=129/0 [00022400-f80001c0] page_structs=131072 node=0 entry=144/0 [00022400-f8000200] page_structs=131072 node=0 entry=145/0 Zone PFN ranges: Normal 0x - 0x0091ff6e Movable zone start PFN for each node early_node_map[7] active PFN ranges 0: 0x - 0x0002 0: 0x0010 - 0x0012 0: 0x0080 -
Re: Sparc release requalification
From: Josip Rodin j...@entuzijast.net Date: Fri, 11 Sep 2009 21:09:10 +0200 calling pcr_arch_init+0x0/0x130 @ 1 Test Make pcr_arch_init() in arch/sparc/kernel/pcr.c simply return 0 instead of doing anything, see if that helps it get further along. I'll test Dave's image later, and if that fails, I guess it's best to start bisecting? Yes, but if the above fixes things the bisect would almost certainly land on commit: commit e5553a6d04421eec326a629571d696e8e745a0e4 Author: David S. Miller da...@davemloft.net Date: Thu Jan 29 21:22:47 2009 -0800 sparc64: Implement NMI watchdog on capable cpus. Signed-off-by: David S. Miller da...@davemloft.net -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Fri, Sep 11, 2009 at 01:04:33PM -0700, David Miller wrote: From: Josip Rodin j...@entuzijast.net Date: Fri, 11 Sep 2009 21:09:10 +0200 calling pcr_arch_init+0x0/0x130 @ 1 Test Make pcr_arch_init() in arch/sparc/kernel/pcr.c simply return 0 instead of doing anything, see if that helps it get further along. I'll test Dave's image later, and if that fails, I guess it's best to start bisecting? Yes, but if the above fixes things the bisect would almost certainly land on commit: commit e5553a6d04421eec326a629571d696e8e745a0e4 Author: David S. Miller da...@davemloft.net Date: Thu Jan 29 21:22:47 2009 -0800 sparc64: Implement NMI watchdog on capable cpus. You're right, that new code is causing the crash, on this hardware at least. Your image failed to boot the same way - four characters into the printk(), it dies. In my case, I didn't seem to have any problems when I just turned it off in pcr_arch_init(). I added some poor man's debugging and got: calling pcr_arch_init+0x0/0x13c @ 1 Most of pcr_arch_init() is done, going for nmi_init()... This is start_watchdog(), writing picl_value(nmi_hz)=-17214228922368000 into pic... This is start_watchdog(), writing picl_value(nmi_hz)=-17214228922368000 into pic... This That last line was a printk() right after the on_each_cpu(start_watchdog, NULL, 1); call. Again exactly four characters into the printk. Sébastien also mentioned that the kernel with many debug printks kept crashing for him. Could this consistency be of any significance, maybe the printk functions are somehow problematic... so I fiddled with them some more, but it looks more like they just waste time until something kicks in and somehow kills the kernel without a trace. That doesn't sound like perfctr_irq() and die_nmi(), but then I don't really any idea how exactly all that works :) I'm attaching the kernel config, if you need anything else, just let me know. -- 2. That which causes joy or happiness. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.31 # Fri Sep 11 18:23:35 2009 # CONFIG_64BIT=y CONFIG_SPARC=y # CONFIG_SPARC32 is not set CONFIG_SPARC64=y CONFIG_ARCH_DEFCONFIG=arch/sparc/configs/sparc64_defconfig CONFIG_BITS=64 CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_IOMMU_HELPER=y CONFIG_QUICKLIST=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_AUDIT_ARCH=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_HAVE_DYNAMIC_PER_CPU_AREA=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_MMU=y CONFIG_ARCH_NO_VIRT_TO_BUS=y CONFIG_OF=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_CONSTRUCTORS=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # # RCU Subsystem # CONFIG_CLASSIC_RCU=y # CONFIG_TREE_RCU is not set # CONFIG_PREEMPT_RCU is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_PREEMPT_RCU_TRACE is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=15 # CONFIG_GROUP_SCHED is not set # CONFIG_CGROUPS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_RELAY=y CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_NET_NS is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y # # Performance Counters # CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y # CONFIG_STRIP_ASM_SYMS is not set CONFIG_COMPAT_BRK=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set # CONFIG_PROFILING is not set # CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_SYSCALL_WRAPPERS=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_USE_GENERIC_SMP_HELPERS=y # # GCOV-based kernel profiling # # CONFIG_GCOV_KERNEL is not set # CONFIG_SLOW_WORK is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_BSG is not set #
Re: Sparc release requalification
From: Josip Rodin j...@entuzijast.net Date: Sat, 12 Sep 2009 01:04:16 +0200 In my case, I didn't seem to have any problems when I just turned it off in pcr_arch_init(). Yeah, that's usually what cures this. I added some poor man's debugging and got: calling pcr_arch_init+0x0/0x13c @ 1 Most of pcr_arch_init() is done, going for nmi_init()... This is start_watchdog(), writing picl_value(nmi_hz)=-17214228922368000 into pic... This is start_watchdog(), writing picl_value(nmi_hz)=-17214228922368000 into pic... This That last line was a printk() right after the on_each_cpu(start_watchdog, NULL, 1); call. Again exactly four characters into the printk. Yeah, that's when it's going to take the first NMI. Could this consistency be of any significance, maybe the printk functions are somehow problematic... so I fiddled with them some more, but it looks more like they just waste time until something kicks in and somehow kills the kernel without a trace. That doesn't sound like perfctr_irq() and die_nmi(), but then I don't really any idea how exactly all that works :) You can't put debugging print statements in the NMI irq handlers like perfctr_irq(), that will almost always cause a lockup or crash. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
David Miller a écrit :
From: Sébastien Bernard s...@sfrdev.fr
Date: Mon, 07 Sep 2009 18:53:15 +0200
David Miller a écrit :
[great explanation snipped]
--- a/arch/sparc/kernel/nmi.c
+++ b/arch/sparc/kernel/nmi.c
@@ -103,7 +103,7 @@ notrace __kprobes void perfctr_irq(int irq, struct
pt_regs *regs)
}
if (!touched __get_cpu_var(last_irq_sum) == sum) {
local_inc(__get_cpu_var(alert_counter));
- if (local_read(__get_cpu_var(alert_counter)) == 5 * nmi_hz)
+ if (local_read(__get_cpu_var(alert_counter)) == 30 * nmi_hz)
die_nmi(BUG: NMI Watchdog detected LOCKUP,
regs, panic_on_timeout);
} else {
Hum, I tested today, and no, it does not solve the problem. Kernel is
still hanging at the same place.
I'll get the initcall debug back when I'll have rebuild a kernel
withtou the config_prom_console.
Then what bug are you talking about?
You stated that disabling the NMI watchdog completely solves your
problem right? That's why I mentioned the above patch to you?
My mistake, I didn't look the log hard enough.
I rebuild a new kernel (2.6.31-rc9) with no patch and there was no hang.
It passes the nmi_setup but crashes further when mounting the root
partition.
I'll send the complete logs further.
The funny part is that booting with debug_initcalls=1 makes the kernel
hangs.
Seb
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
David Miller a écrit :
[great explanation snipped]
--- a/arch/sparc/kernel/nmi.c
+++ b/arch/sparc/kernel/nmi.c
@@ -103,7 +103,7 @@ notrace __kprobes void perfctr_irq(int irq, struct pt_regs
*regs)
}
if (!touched __get_cpu_var(last_irq_sum) == sum) {
local_inc(__get_cpu_var(alert_counter));
- if (local_read(__get_cpu_var(alert_counter)) == 5 * nmi_hz)
+ if (local_read(__get_cpu_var(alert_counter)) == 30 * nmi_hz)
die_nmi(BUG: NMI Watchdog detected LOCKUP,
regs, panic_on_timeout);
} else {
Hum, I tested today, and no, it does not solve the problem. Kernel is
still hanging at the same place.
I'll get the initcall debug back when I'll have rebuild a kernel withtou
the config_prom_console.
Seb
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
From: Sébastien Bernard s...@sfrdev.fr
Date: Mon, 07 Sep 2009 18:53:15 +0200
David Miller a écrit :
[great explanation snipped]
--- a/arch/sparc/kernel/nmi.c
+++ b/arch/sparc/kernel/nmi.c
@@ -103,7 +103,7 @@ notrace __kprobes void perfctr_irq(int irq, struct
pt_regs *regs)
}
if (!touched __get_cpu_var(last_irq_sum) == sum) {
local_inc(__get_cpu_var(alert_counter));
-if (local_read(__get_cpu_var(alert_counter)) == 5 * nmi_hz)
+ if (local_read(__get_cpu_var(alert_counter)) == 30 * nmi_hz)
die_nmi(BUG: NMI Watchdog detected LOCKUP,
regs, panic_on_timeout);
} else {
Hum, I tested today, and no, it does not solve the problem. Kernel is
still hanging at the same place.
I'll get the initcall debug back when I'll have rebuild a kernel
withtou the config_prom_console.
Then what bug are you talking about?
You stated that disabling the NMI watchdog completely solves your
problem right? That's why I mentioned the above patch to you?
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Thu, Aug 20, 2009 at 12:20:01PM +0200, Matthias Klose wrote: On 19.08.2009 16:33, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:55:24PM +0200, Matthias Klose wrote: On 19.08.2009 13:42, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote: I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - have an inplace-transition building required library packages for an upgrade as biarch packages and continue to use the current sparc name. This would mean that many packages needs to be modified. Is it really worth the work needed if we consider the availability of multiarch in the next time? you'll end up modifying a different set of packages for the new architecture name in control and rules files. I don't know if this is less or more work. If I understand this correctly, this would need the modification off all library packages to implement biarch semantic. No, just a subset that an update from 32-64bit userland does work. Again, I don't know how big this subset will be. Matthias, can you please make a definite statement on whether you, as a toolchain maintainer, are willing to support the existing 32-bit userland with a 64-bit kernel, or you consider a transition to 64-bit userland a necessary condition for sparc to be released with squeeze. This will be an important factor for the release team to determine what is going to happen. Thanks. -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Sat, 22 Aug 2009 21:32:43 +0100, Josip Rodin Wrote :
[dropping debian-release, as it's not very interesting for them anymore]
On Wed, Aug 19, 2009 at 12:00:54AM +0200, Josip Rodin wrote:
On Tue, Aug 18, 2009 at 10:30:29PM +0100, Jurij Smakov wrote:
the sid kernels are not booting on my machine (SunBlade 1000), and I
have
an independent confirmation from someone with a similar machine that
they
are experiencing similar problems - I'm going to file a bug for that if
the situation does not improve with the next kernel upload.
What seems to be the problem? FWIW the prtconfs.git repo has two SB1000
entries one of which is davem's, so we should have upstream support for
this at least.
After the message mentioning the console handoff from earlyprom to a real
console it proceeds to clear the screen, however after a couple of lines
it hangs.
Did you try to avoid the handoff? That patch davem keeps telling people to
try when something like this happens:
--- a/arch/sparc64/kernel/setup.c
+++ b/arch/sparc64/kernel/setup.c
@@ -82,7 +82,7 @@ unsigned long cmdline_memory_size = 0;
static struct console prom_early_console = {
.name = earlyprom,
.write =prom_console_write,
- .flags =CON_PRINTBUFFER | CON_BOOT | CON_ANYTIME,
+ .flags =CON_PRINTBUFFER | CON_ANYTIME,
.index =-1,
};
I tried this patch, and the box still hangs early during boot with the
latest kernel from unstable, even though console handover does not
appear to be happening anymore. Here's the last screenful of messages
I see on the serial console:
[0.00] Kernel: Using 2 locked TLB entries for main kernel image.
[0.00] Remapping the kernel... done.
[0.00] OF stdout device is: /p...@8,70/e...@5/ser...@1,40:a
[0.00] PROM: Built device tree with 73716 bytes of memory.
[0.00] Top of RAM: 0x7fede000, Total RAM: 0x7fed6000
[0.00] Memory hole size: 0MB
[0.00] [0002-f840] page_structs=131072 node=0
entry=0/0
[0.00] [0002-f880] page_structs=131072 node=0
entry=1/0
[0.00] [00020080-f8c0] page_structs=131072 node=0
entry=2/0
[0.00] [00020080-f8000100] page_structs=131072 node=0
entry=3/0
[0.00] Zone PFN ranges:
[0.00] Normal 0x - 0x0003ff6f
[0.00] Movable zone start PFN for each node
[0.00] early_node_map[3] active PFN ranges
[0.00] 0: 0x - 0x0003f7ff
[0.00] 0: 0x0003f800 - 0x0003ff5d
[0.00] 0: 0x0003ff60 - 0x0003ff6f
[0.00] Booting Linux...
[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 259948
[0.00] Kernel command line: root=LABEL=root ro
[0.00] NR_IRQS:255
[0.00] PID hash table entries: 4096 (order: 12, 32768 bytes)
[0.00] clocksource: mult[c8] shift[16]
[0.00] clockevent: mult[147ae14] shift[32]
[ 57.812617] Console: colour dummy device 80x25
[ 57.865696] console [tty0] enabled
[ 60.031281] Dentry cache hash table entries: 262144 (order: 8, 2097152 bytes)
[ 60.120115] Inode-cache hash table entries: 131072 (order: 7, 1048576 bytes)
[ 60.311406] Memory: 2062032k available (3304k kernel code, 1248k data, 208k
init) [f800,7fede000]
[ 60.516890] Calibrating delay using timer specific routine.. 10.00 BogoMIPS
(lpj=20015)
[ 60.611164] Security Framework initialized
[ 60.659890] SELinux: Disabled at boot.
[ 60.705771] Mount-cache hash table entries: 512
[ 60.760489] Initializing cgroup subsys ns
[ 60.807803] Initializing cgroup subsys cpuacct
[ 60.860920] Initializing cgroup subsys devices
[ 60.914042] Initializing cgroup subsys freezer
[ 60.967166] Initializing cgroup subsys net_cls
[ 61.022918] CPU 1: synchronized TICK with master CPU (last diff 0 cycles,
maxerr 5 cycles)
[ 61.022933] Brought up 2 CPUs
[ 61.024050] net_namespace: 1936 bytes
[ 61.200137] regulator: core version 0.5
[ 61.245754] NET: Registered protocol family 16
[ 61
It just hangs right there, with the last string only partially displayed
and cursor blinking right after '61'.
Best regards,
--
Jurij Smakov ju...@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
I think you hit the same bug as I do on my V240 (same hardware I think).
Please Check this patch and see if it resolves your problem :
http://marc.info/?l=linux-sparcm=123922959800843w=2
http://marc.info/?l=linux-sparcm=123922959800843w=2
You can also check the whole thread. At the present time, the kernel
still freezes if this patch is not applied.
Unfortunately, all kernel now from debian or derived distribution are
hanging my machine. There is no workaroung but
disabling the NMI watchdog by this patch.
Re: Sparc release requalification
From: Sébastien Bernard sbern...@nerim.net
Date: Sun, 06 Sep 2009 23:21:42 +0200
David said, he'll look this bug later. I'll need to remind him.
In Linus's tree is the following fix for this. I'll submit it
to -stable when I get a chance.
sparc64: Kill spurious NMI watchdog triggers by increasing limit to 30 seconds.
This is a compromise and a temporary workaround for bootup NMI
watchdog triggers some people see with qla2xxx devices present.
This happens when, for example:
CPU 0 is in the driver init and looping submitting mailbox commands to
load the firmware, then waiting for completion.
CPU 1 is receiving the device interrupts. CPU 1 is where the NMI
watchdog triggers.
CPU 0 is submitting mailbox commands fast enough that by the time CPU
1 returns from the device interrupt handler, a new one is pending.
This sequence runs for more than 5 seconds.
The problematic case is CPU 1's timer interrupt running when the
barrage of device interrupts begin. Then we have:
timer interrupt
return for softirq checking
pending, thus enable interrupts
qla2xxx interrupt
return
qla2xxx interrupt
return
... 5+ seconds pass
final qla2xxx interrupt for fw load
return
run timer softirq
return
At some point in the multi-second qla2xxx interrupt storm we trigger
the NMI watchdog on CPU 1 from the NMI interrupt handler.
The timer softirq, once we get back to running it, is smart enough to
run the timer work enough times to make up for the missed timer
interrupts.
However, the NMI watchdogs (both x86 and sparc) use the timer
interrupt count to notice the cpu is wedged. But in the above
scenerio we'll receive only one such timer interrupt even if we last
all the way back to running the timer softirq.
The default watchdog trigger point is only 5 seconds, which is pretty
low (the softwatchdog triggers at 60 seconds). So increase it to 30
seconds for now.
Signed-off-by: David S. Miller da...@davemloft.net
---
arch/sparc/kernel/nmi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/sparc/kernel/nmi.c b/arch/sparc/kernel/nmi.c
index 2c0cc72..b75bf50 100644
--- a/arch/sparc/kernel/nmi.c
+++ b/arch/sparc/kernel/nmi.c
@@ -103,7 +103,7 @@ notrace __kprobes void perfctr_irq(int irq, struct pt_regs
*regs)
}
if (!touched __get_cpu_var(last_irq_sum) == sum) {
local_inc(__get_cpu_var(alert_counter));
- if (local_read(__get_cpu_var(alert_counter)) == 5 * nmi_hz)
+ if (local_read(__get_cpu_var(alert_counter)) == 30 * nmi_hz)
die_nmi(BUG: NMI Watchdog detected LOCKUP,
regs, panic_on_timeout);
} else {
--
1.6.4.2
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
[dropping debian-release, as it's not very interesting for them anymore]
On Wed, Aug 19, 2009 at 12:00:54AM +0200, Josip Rodin wrote:
On Tue, Aug 18, 2009 at 10:30:29PM +0100, Jurij Smakov wrote:
the sid kernels are not booting on my machine (SunBlade 1000), and I
have
an independent confirmation from someone with a similar machine that
they
are experiencing similar problems - I'm going to file a bug for that if
the situation does not improve with the next kernel upload.
What seems to be the problem? FWIW the prtconfs.git repo has two SB1000
entries one of which is davem's, so we should have upstream support for
this at least.
After the message mentioning the console handoff from earlyprom to a real
console it proceeds to clear the screen, however after a couple of lines
it hangs.
Did you try to avoid the handoff? That patch davem keeps telling people to
try when something like this happens:
--- a/arch/sparc64/kernel/setup.c
+++ b/arch/sparc64/kernel/setup.c
@@ -82,7 +82,7 @@ unsigned long cmdline_memory_size = 0;
static struct console prom_early_console = {
.name = earlyprom,
.write =prom_console_write,
- .flags =CON_PRINTBUFFER | CON_BOOT | CON_ANYTIME,
+ .flags =CON_PRINTBUFFER | CON_ANYTIME,
.index =-1,
};
I tried this patch, and the box still hangs early during boot with the
latest kernel from unstable, even though console handover does not
appear to be happening anymore. Here's the last screenful of messages
I see on the serial console:
[0.00] Kernel: Using 2 locked TLB entries for main kernel image.
[0.00] Remapping the kernel... done.
[0.00] OF stdout device is: /p...@8,70/e...@5/ser...@1,40:a
[0.00] PROM: Built device tree with 73716 bytes of memory.
[0.00] Top of RAM: 0x7fede000, Total RAM: 0x7fed6000
[0.00] Memory hole size: 0MB
[0.00] [0002-f840] page_structs=131072 node=0
entry=0/0
[0.00] [0002-f880] page_structs=131072 node=0
entry=1/0
[0.00] [00020080-f8c0] page_structs=131072 node=0
entry=2/0
[0.00] [00020080-f8000100] page_structs=131072 node=0
entry=3/0
[0.00] Zone PFN ranges:
[0.00] Normal 0x - 0x0003ff6f
[0.00] Movable zone start PFN for each node
[0.00] early_node_map[3] active PFN ranges
[0.00] 0: 0x - 0x0003f7ff
[0.00] 0: 0x0003f800 - 0x0003ff5d
[0.00] 0: 0x0003ff60 - 0x0003ff6f
[0.00] Booting Linux...
[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 259948
[0.00] Kernel command line: root=LABEL=root ro
[0.00] NR_IRQS:255
[0.00] PID hash table entries: 4096 (order: 12, 32768 bytes)
[0.00] clocksource: mult[c8] shift[16]
[0.00] clockevent: mult[147ae14] shift[32]
[ 57.812617] Console: colour dummy device 80x25
[ 57.865696] console [tty0] enabled
[ 60.031281] Dentry cache hash table entries: 262144 (order: 8, 2097152 bytes)
[ 60.120115] Inode-cache hash table entries: 131072 (order: 7, 1048576 bytes)
[ 60.311406] Memory: 2062032k available (3304k kernel code, 1248k data, 208k
init) [f800,7fede000]
[ 60.516890] Calibrating delay using timer specific routine.. 10.00 BogoMIPS
(lpj=20015)
[ 60.611164] Security Framework initialized
[ 60.659890] SELinux: Disabled at boot.
[ 60.705771] Mount-cache hash table entries: 512
[ 60.760489] Initializing cgroup subsys ns
[ 60.807803] Initializing cgroup subsys cpuacct
[ 60.860920] Initializing cgroup subsys devices
[ 60.914042] Initializing cgroup subsys freezer
[ 60.967166] Initializing cgroup subsys net_cls
[ 61.022918] CPU 1: synchronized TICK with master CPU (last diff 0 cycles,
maxerr 5 cycles)
[ 61.022933] Brought up 2 CPUs
[ 61.024050] net_namespace: 1936 bytes
[ 61.200137] regulator: core version 0.5
[ 61.245754] NET: Registered protocol family 16
[ 61
It just hangs right there, with the last string only partially displayed
and cursor blinking right after '61'.
Best regards,
--
Jurij Smakov ju...@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Sat, Aug 22, 2009 at 09:32:43PM +0100, Jurij Smakov wrote:
the sid kernels are not booting on my machine (SunBlade 1000), and I
have
an independent confirmation from someone with a similar machine that
they
are experiencing similar problems - I'm going to file a bug for that
if
the situation does not improve with the next kernel upload.
What seems to be the problem? FWIW the prtconfs.git repo has two SB1000
entries one of which is davem's, so we should have upstream support for
this at least.
After the message mentioning the console handoff from earlyprom to a real
console it proceeds to clear the screen, however after a couple of lines
it hangs.
Did you try to avoid the handoff? That patch davem keeps telling people to
try when something like this happens:
--- a/arch/sparc64/kernel/setup.c
+++ b/arch/sparc64/kernel/setup.c
@@ -82,7 +82,7 @@ unsigned long cmdline_memory_size = 0;
static struct console prom_early_console = {
.name = earlyprom,
.write =prom_console_write,
- .flags =CON_PRINTBUFFER | CON_BOOT | CON_ANYTIME,
+ .flags =CON_PRINTBUFFER | CON_ANYTIME,
.index =-1,
};
I tried this patch, and the box still hangs early during boot with the
latest kernel from unstable, even though console handover does not
appear to be happening anymore. Here's the last screenful of messages
I see on the serial console:
[ 61.022933] Brought up 2 CPUs
[ 61.024050] net_namespace: 1936 bytes
[ 61.200137] regulator: core version 0.5
[ 61.245754] NET: Registered protocol family 16
[ 61
It just hangs right there, with the last string only partially displayed
and cursor blinking right after '61'.
Ugh. I guess you need to git bisect then.
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Thu, Aug 20, 2009 at 07:09:44AM +0200, Mike Hommey wrote: On Wed, Aug 19, 2009 at 04:33:32PM +0200, Bastian Blank wrote: If I understand this correctly, this would need the modification off all library packages to implement biarch semantic. ... which will be needed anyways. So your choice is actually between doing it and doing it plus some extra intermediate work. No, we don't need to do that. Thats what is multiarch for. Bastian -- Captain's Log, star date 21:34.5... -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Thu, Aug 20, 2009 at 10:45:46AM +0200, Bastian Blank wrote: On Thu, Aug 20, 2009 at 07:09:44AM +0200, Mike Hommey wrote: On Wed, Aug 19, 2009 at 04:33:32PM +0200, Bastian Blank wrote: If I understand this correctly, this would need the modification off all library packages to implement biarch semantic. ... which will be needed anyways. So your choice is actually between doing it and doing it plus some extra intermediate work. No, we don't need to do that. Thats what is multiarch for. It's not intended that multiarch supports switching architectures. Of course it would help to import some 64bit packages selectively from a sparc64 port but most of your binaries would still be 32bit with the only partially supported code generation? Even on a rebuild you would have to pull in the 64bit libs in a way you build against them by default? (Or would that boil down to passing another DEB_*_ARCH so that config.guess targets 64bit and stuffing that into simple packages with arch:sparc?) Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Re: Sparc release requalification
On 19.08.2009 16:33, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:55:24PM +0200, Matthias Klose wrote: On 19.08.2009 13:42, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote: I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - have an inplace-transition building required library packages for an upgrade as biarch packages and continue to use the current sparc name. This would mean that many packages needs to be modified. Is it really worth the work needed if we consider the availability of multiarch in the next time? you'll end up modifying a different set of packages for the new architecture name in control and rules files. I don't know if this is less or more work. If I understand this correctly, this would need the modification off all library packages to implement biarch semantic. No, just a subset that an update from 32-64bit userland does work. Again, I don't know how big this subset will be. Matthias -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Thu, Aug 20, 2009 at 10:53:08AM +0200, Philipp Kern wrote: It's not intended that multiarch supports switching architectures. It's also just an upgrade. Or did I miss something that would make it impossible to replace perl/i386 with perl/amd64? Bastian -- Many Myths are based on truth -- Spock, The Way to Eden, stardate 5832.3 -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
Bastian Blank a écrit : On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote: I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - define a new sparc64 port, and bootstrap this one using the 32bit port. This is rather easy. I already did a s390x bootstrap using this method. If we are not sure that sparc and s390 (ie 32-bit versions) would be suitable for squeeze, this is almost sure they won't be suitable for squeeze+1. Isn't it the right moment to start a sparc64 and an s390x port, and if they are ready for squeeze release with them? Almost whatever upgrade solution you offer will require to have at least one release with both old and new architecture (like we did for arm - armel). Given that we already have sparc and s390 in the archive and that we also already have 64-bit ports, I don't expect any major problem for those new ports. Also given quite fast hardware exists for those architectures, it can probably be done relatively quickly. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On 18.08.2009 22:43, Jurij Smakov wrote: Hello, I would like to point out that sparc release requalification is currently placing it in at risk position for squeeze release. The most serious problems with the port are lack of developer involvement (there is currently one active porter/developer known to the release team, Bernd Zeimetz) and the fact that current mixed 64-bit kernel with 32-bit userspace setup is not supported upstream (CC'ing doko for comment). The current configuration for a biarch toolchain defaulting to 32-bit isn't that well supported. The 32-bit compiler defaults to v8 hardware which isn't available anymore. The biarch setup tightly couples v9 and newer processor support to 64-bit, so switching to a 64-bit userland would offer better use of current hardware besides targeting a comparable setup as other distributions. Newer projects like llvm don't target 32-bit sparc anymore, while they do for 64-bit. I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - define a new sparc64 port, and bootstrap this one using the 32bit port. - have an inplace-transition building required library packages for an upgrade as biarch packages and continue to use the current sparc name. For both variants the toolchain is almost in place. glibc and binutils don't need modifications, gcc needs some libraries be built as biarch on sparc. zlib is already built as biarch on sparc. gmp and mpfr are already built as biarch on other archs, ppl and cloog would be good to have, but we could start without the graphite optimizations as well. I can prepare the changes for gcc, but will not help with any other transition work. [CCing debian-s390, because there are plans for a switch to s390x as well] Matthias -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote: I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - define a new sparc64 port, and bootstrap this one using the 32bit port. This is rather easy. I already did a s390x bootstrap using this method. - have an inplace-transition building required library packages for an upgrade as biarch packages and continue to use the current sparc name. This would mean that many packages needs to be modified. Is it really worth the work needed if we consider the availability of multiarch in the next time? Bastian -- He's dead, Jim. -- McCoy, The Devil in the Dark, stardate 3196.1 -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On 19.08.2009 13:42, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote: I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - define a new sparc64 port, and bootstrap this one using the 32bit port. This is rather easy. I already did a s390x bootstrap using this method. - have an inplace-transition building required library packages for an upgrade as biarch packages and continue to use the current sparc name. This would mean that many packages needs to be modified. Is it really worth the work needed if we consider the availability of multiarch in the next time? you'll end up modifying a different set of packages for the new architecture name in control and rules files. I don't know if this is less or more work. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Wed, Aug 19, 2009 at 01:55:24PM +0200, Matthias Klose wrote: On 19.08.2009 13:42, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote: I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - have an inplace-transition building required library packages for an upgrade as biarch packages and continue to use the current sparc name. This would mean that many packages needs to be modified. Is it really worth the work needed if we consider the availability of multiarch in the next time? you'll end up modifying a different set of packages for the new architecture name in control and rules files. I don't know if this is less or more work. If I understand this correctly, this would need the modification off all library packages to implement biarch semantic. Bastian -- Star Trek Lives! -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Wed, Aug 19, 2009 at 04:33:32PM +0200, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:55:24PM +0200, Matthias Klose wrote: On 19.08.2009 13:42, Bastian Blank wrote: On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote: I did speak with Martin Zobel at Debconf on how to get there, having two proposals: - have an inplace-transition building required library packages for an upgrade as biarch packages and continue to use the current sparc name. This would mean that many packages needs to be modified. Is it really worth the work needed if we consider the availability of multiarch in the next time? you'll end up modifying a different set of packages for the new architecture name in control and rules files. I don't know if this is less or more work. If I understand this correctly, this would need the modification off all library packages to implement biarch semantic. ... which will be needed anyways. So your choice is actually between doing it and doing it plus some extra intermediate work. Mike -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Tue, Aug 18, 2009 at 09:43:35PM +0100, Jurij Smakov wrote: the sid kernels are not booting on my machine (SunBlade 1000), and I have an independent confirmation from someone with a similar machine that they are experiencing similar problems - I'm going to file a bug for that if the situation does not improve with the next kernel upload. What seems to be the problem? FWIW the prtconfs.git repo has two SB1000 entries one of which is davem's, so we should have upstream support for this at least. Regarding the sparc kernel, it has recently seen a significant amount of work esp. on 32-bit support, and in fact a new 32-bit subarch Leon was just added, so we may actually be in a better situation than in lenny on that front. The outlook certainly seems to be less gloomy than before. (on a somewhat brighter note, Stephen Gran has reported an almost successful install on T2K recently [0]) (Is that the newly donated machine that we had been talking about a while ago?) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Tue, Aug 18, 2009 at 11:23:27PM +0200, Josip Rodin wrote: On Tue, Aug 18, 2009 at 09:43:35PM +0100, Jurij Smakov wrote: the sid kernels are not booting on my machine (SunBlade 1000), and I have an independent confirmation from someone with a similar machine that they are experiencing similar problems - I'm going to file a bug for that if the situation does not improve with the next kernel upload. What seems to be the problem? FWIW the prtconfs.git repo has two SB1000 entries one of which is davem's, so we should have upstream support for this at least. After the message mentioning the console handoff from earlyprom to a real console it proceeds to clear the screen, however after a couple of lines it hangs. Regarding the sparc kernel, it has recently seen a significant amount of work esp. on 32-bit support, and in fact a new 32-bit subarch Leon was just added, so we may actually be in a better situation than in lenny on that front. The outlook certainly seems to be less gloomy than before. (on a somewhat brighter note, Stephen Gran has reported an almost successful install on T2K recently [0]) (Is that the newly donated machine that we had been talking about a while ago?) No idea about that. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
On Tue, Aug 18, 2009 at 10:30:29PM +0100, Jurij Smakov wrote:
the sid kernels are not booting on my machine (SunBlade 1000), and I have
an independent confirmation from someone with a similar machine that they
are experiencing similar problems - I'm going to file a bug for that if
the situation does not improve with the next kernel upload.
What seems to be the problem? FWIW the prtconfs.git repo has two SB1000
entries one of which is davem's, so we should have upstream support for
this at least.
After the message mentioning the console handoff from earlyprom to a real
console it proceeds to clear the screen, however after a couple of lines
it hangs.
Did you try to avoid the handoff? That patch davem keeps telling people to
try when something like this happens:
--- a/arch/sparc64/kernel/setup.c
+++ b/arch/sparc64/kernel/setup.c
@@ -82,7 +82,7 @@ unsigned long cmdline_memory_size = 0;
static struct console prom_early_console = {
.name = earlyprom,
.write =prom_console_write,
- .flags =CON_PRINTBUFFER | CON_BOOT | CON_ANYTIME,
+ .flags =CON_PRINTBUFFER | CON_ANYTIME,
.index =-1,
};
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sparc release requalification
Josip, am Tue, Aug 18, 2009 at 11:23:27PM +0200 hast du folgendes geschrieben: (on a somewhat brighter note, Stephen Gran has reported an almost successful install on T2K recently [0]) (Is that the newly donated machine that we had been talking about a while ago?) donated to Debian years ago, only DSA'ed very, very recently. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
