On Mon, Oct 13, 2003 at 06:27:43PM +0200, Sven Luther wrote: > On Mon, Oct 13, 2003 at 09:04:49AM -0600, LaMont Jones wrote: > > On Mon, Oct 13, 2003 at 10:09:17AM +0200, Sven Luther wrote: > > > On Mon, Oct 13, 2003 at 09:41:35AM +0200, Stefano Zacchiroli wrote: > > > > On Mon, Oct 13, 2003 at 09:17:59AM +0200, Sven Luther wrote: > > > Ok, but now we have the hppa autobuilder maintainer looking at it > > > (hopefully) so we will know more about it. I CC him on this mail, so he > > > will know about your experience. > Cool, but i suppose this means the problem is not really solved, right ?
That or ocaml works around it... > > it down. The unaligned handler does somewhat throttled printks (They're > > only throttled within the process, running another one will keep them > > coming.) With as many as ocaml's build was generating, I expect that was > > why the system was crashing. > So a kernel issue ? That part is. Basically an ocaml? feature? exercising a kernel defect. Two independent problems working together to make my life difficult... :-) > That feels strange, since on hppa, only the bytecode compiler is > available, and the bytecode stuff, to the best of my knowledge, has > everything 32bit aligned. ... Mmm, you are speaking about 16 byte (as in > 16 x 8 = 128 bit alignement ?). I will investigate with upstream for > this. Is this only for floats, or for everything ? fstd (128 bit store) is used in setjmp to save state - unless ocaml is generating its own hppa assembly (and using fstd...), then it's elsewhere. I'm not aware of the compiler generating that instr other than when doing quad floats. > Also, if there needs to be a change in ocaml, would it be possible to > have an account for upstream on a hppa box so he can track (and fix) the > issue ? We should be able to arrange this. One should poke taggart or willy to create the account on paer (or some other parisc box at hp...) > > But again, it seems to be working now, at least on machines that raise > > SIGBUS on unaligned loads/stores. > Ok, but may be broken again in the future, best would be to solve this > for in ocaml if possible. And it may crash machines that don't raise it... It would be good to fix. lamont
