On Tue, Nov 05, 2013 at 12:15:35PM +0400, Boris Bobrov wrote: B> В сообщении от Tuesday 05 of November 2013 11:06:09 Gleb написал: B> > On Tue, Nov 05, 2013 at 09:02:22AM +0200, Konstantin Belousov wrote: B> > K> First, all reported instances have ata attachment for the ada0, B> > except K> of milu (possibly). So this means that kernel does transient B> > remapping, K> and very different code path is executed comparing with B> > what I thought K> initially. The path is simpler than the pure B> > unmapped i/o. B> > K> B> > K> Second, I use QEMU with the ata0 attachment for the disks regularly, B> > and K> I do not have an issue. I also did not see a report from the B> > real h/w. K> B> > K> Third point is that all reports are i386. Is there anybody with B> > amd64, K> vbox, ata and the same corruption hiddent by disabling B> > unmapped i/o ? K> B> > K> In what way the non-working images were installed ? Is it possible B> > to K> produce the problematic installs by doing it one way, and B> > non-problematic K> by another ? B> > B> > The only known way to get FreeBSD working is to turn off unmapped io B> > in loader. Any tweaking of "hardware" in VB or changes in the install B> > process do not affect. B> B> Disabling VT-x in VB helps too.
Doesn't help with my issue. This could mean that my issue and the one that Boris and Maciej encountered are different. -- Totus tuus, Glebius. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"