diff for duplicates of <20170922163753.GA2415@localhost.localdomain> diff --git a/a/1.txt b/N1/1.txt index a6b3d45..66810aa 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -39,38 +39,3 @@ console is ready, hence nothing is displayed. Is there a practical way to postpone or recover from a trap? The issue becomes somewhat involved since the trap needs to save/restore registers for itself to recover, and so might evoke boundless recursion. - -From a practical point of view it would be great if backtraces could be -rate limited, recoverable and possible to copy over network (I don't have -e.g. a serial port soldered). I will look into other alternatives to try -to capture this. - -> Previously you wrote that the problem is with resetting the upper 96 bits -> (how did you notice that BTW?) rather than bits 63:32 only, so you need a -> different check. - -I suspect 63:32 are the critical bits of the upper 96 bits since SD/LD -is sufficient. Summery of observations thus far: save/restore works with -SQ/LQ and SD/LD, but not SW/LW, in a 32-bit kernel ceteris paribus. - -> Also I see no reason why LW would set bits 63:32 to anything different -> from what was there before SW as long as the original value was 32-bit -> (hence the second check sequence proposed). - -Yes, SLL seems sufficient for testing this. - -> > A question is whether registers are clobbered within the kernel itself -> > (via interrupts or some such) or for user programs. -> -> Well, you do need to verify your patches for such a possibility, right. -> I would advise double-checking exception handling indeed, including -> run-time generated exception handler code in particular. - -The extremely early trap indicates a kernel issue, or perhaps register -garbage during kernel initialisation, that wouldn't be an error? Is the -run-time code related to genex.S? The R5900 patch sprinkles NOP and -SYNC.P instructions on it, for various workarounds, but not much else -apart from reverting db8466c581c "MIPS: IRQ Stack: Unwind IRQ stack onto -task stack" that otherwise crashes for an unknown reason. - -Fredrik diff --git a/a/content_digest b/N1/content_digest index 3ba5b07..fb2832c 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -51,41 +51,6 @@ "console is ready, hence nothing is displayed. Is there a practical way\n" "to postpone or recover from a trap? The issue becomes somewhat involved\n" "since the trap needs to save/restore registers for itself to recover,\n" - "and so might evoke boundless recursion.\n" - "\n" - "From a practical point of view it would be great if backtraces could be\n" - "rate limited, recoverable and possible to copy over network (I don't have\n" - "e.g. a serial port soldered). I will look into other alternatives to try\n" - "to capture this.\n" - "\n" - "> Previously you wrote that the problem is with resetting the upper 96 bits \n" - "> (how did you notice that BTW?) rather than bits 63:32 only, so you need a \n" - "> different check.\n" - "\n" - "I suspect 63:32 are the critical bits of the upper 96 bits since SD/LD\n" - "is sufficient. Summery of observations thus far: save/restore works with\n" - "SQ/LQ and SD/LD, but not SW/LW, in a 32-bit kernel ceteris paribus.\n" - "\n" - "> Also I see no reason why LW would set bits 63:32 to anything different\n" - "> from what was there before SW as long as the original value was 32-bit\n" - "> (hence the second check sequence proposed).\n" - "\n" - "Yes, SLL seems sufficient for testing this.\n" - "\n" - "> > A question is whether registers are clobbered within the kernel itself\n" - "> > (via interrupts or some such) or for user programs.\n" - "> \n" - "> Well, you do need to verify your patches for such a possibility, right. \n" - "> I would advise double-checking exception handling indeed, including \n" - "> run-time generated exception handler code in particular.\n" - "\n" - "The extremely early trap indicates a kernel issue, or perhaps register\n" - "garbage during kernel initialisation, that wouldn't be an error? Is the\n" - "run-time code related to genex.S? The R5900 patch sprinkles NOP and\n" - "SYNC.P instructions on it, for various workarounds, but not much else\n" - "apart from reverting db8466c581c \"MIPS: IRQ Stack: Unwind IRQ stack onto\n" - "task stack\" that otherwise crashes for an unknown reason.\n" - "\n" - Fredrik + and so might evoke boundless recursion. -e34fc40fb0722a0b1adef6e74e9e4dbe07008092ddc4fd4cd32bdec49df6fdf3 +9434eb5f16bf05cecf3c5048078dfa462ddb846c8fc5ad00e094ff40adc9e738
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.