Hi, > But first step is to get confirmation that reverting this commit > indeed fixes the bug I'll try that. M On Tue, Mar 8, 2011 at 8:37 AM, Marcel van Nies <morcles@xxxxxxxxx> wrote: > Hi, > > It appears that two consecutive commits are causing problems on > hyperSPARC, I noticed that too late. > > Commit 4d14a459857bd151ecbd14bcd37b4628da00792b (the one I reported > earlier) only causes the system to hang, not panic: > [ 11.266665] sd 0:0:1:0: [sda] Attached SCSI disk > [ 11.279998] sd 0:0:3:0: [sdb] Attached SCSI disk > [ 11.299998] kjournald starting. Commit interval 5 seconds > [ 11.303332] EXT3-fs: mounted filesystem with writeback data mode. > [ 11.306665] VFS: Mounted root (ext3 filesystem) readonly on device 8:20. > [ 11.309998] Freeing unused kernel memory: 100k freed > <system hangs here - stop-A does go back to prom> > > and > commit c658ad1b4e1520511da8323aa5e60d444cc303ed > Author: David S. Miller <davem@xxxxxxxxxxxxx> > Date: Fri Dec 11 00:44:47 2009 -0800 > > sparc64: Add syscall tracepoint support. > > Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx> > > actually makes the kernel panic: > [ 11.336665] Freeing unused kernel memory: 100k freed > [ 11.419998] Kernel panic - not syncing: Attempted to kill init! > [ 11.423332] [f002f5b8 : do_group_exit+0x84/0xb4 ] > [f0039490 : get_signal_to_deliver+0x338/0x35c ] > [f00124cc : do_signal+0x30/0x8f0 ] > [f0012da0 : do_notify_resume+0x14/0x38 ] > [f000fca4 : signal_p+0x14/0x24 ] > [f000edfc : srmmu_fault+0x58/0x68 ] > [ 11.466665] Press Stop-A (L1-A) to return to the boot prom > > > Marcel > > > On Tue, Mar 8, 2011 at 8:08 AM, Sam Ravnborg <sam@xxxxxxxxxxxx> wrote: >> On Mon, Mar 07, 2011 at 11:01:20PM -0800, David Miller wrote: >>> From: Sam Ravnborg <sam@xxxxxxxxxxxx> >>> Date: Tue, 8 Mar 2011 07:00:39 +0100 >>> >>> > Added davem... >>> > We see strange SEGV faults in userspace and fail to read from ext2.. >>> > All on some (but not all) sparc32 boxes. >>> >>> I saw the original report. >>> >>> But reverting this commit is the wrong thing to do from what I can >>> tell. >>> >>> Either we have: >>> >>> 1) A compiler code gen bug. >>> >>> 2) Some piece of code which is sparc32 specific is invoking memset >>> or memcpy in a way which makes assumptions which are in fact not >>> valid >>> >>> 3) The code change is merely making cache offsets change, masking the >>> true problem >>> >>> Especially in cases #2 and #3 we're just hiding a heisen-bug and >>> not fixing the real problem. >> Agree on this. >> But first step is to get confirmation that reverting this commit >> indeed fixes the bug. Then we can go hunting for 2), 3) or 1). >> I hope we will find that 2) is the culprint. >> >> Sam >> > -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
