Greg Bonett wrote:
> Many months ago, I believe some *very bad hardware* caused corruption of a
> file on one of my zfs file systems. I've isolated the corrupted file and
> can reliably induce a kernel panic with "touch bad.file", "rm bad.file", or
> "ls -l" in the bad.file's directory (ls in ba
Just some kind of me-too-message.
I had weird things with clang like top crashing as root (but not as
another user) and various ports failing to run with 'illegal instruction'
errors until I removed CPUTYPE?=native.
CPU: Pentium(R) Dual-Core CPU E5200
I did not investigate further, but
I have no problems with CPUTYPE?=native with clang and 9-STABLE,
on Penryn but I only use it for base. There is no correct CPUTYPE
which would correspond to my CPU anyway.
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/FreeBSD-9-amd64-buildworld-stage-4-2-fails-with-cla
And setting "incorrect" CPUTYPE?=native is arguably better than
blindly forcing march flags for whole base build... There are plenty
of parts that don't want any march stuff.
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/FreeBSD-9-amd64-buildworld-stage-4-2-fails-with
Well, now there is release, but -STABLE is still pre, while -STABLE
code is already well past release builds ;)
Eh, imperfect world...
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/9-1-minimal-ram-requirements-tp5771583p5773408.html
Sent from the freebsd-stable mailing
>
> My next plan would be reporting the problem with sufficient
> information so the bug can be fixed.
>
> Destroying the dataset or the whole pool seems like papering over the
> real issue to me and you could still do it if the PR gets ignored for
> too long or a developer agrees that this is the
