Date: Sat, 15 Jan 2022 15:00:15 +0000 From: bugzilla-noreply@freebsd.org To: standards@FreeBSD.org Subject: [Bug 255072] boot (legacy): no progress beyond 'BIOS DRIVE D: is disk1' Message-ID: <bug-255072-99-vOn12ZHRMj@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-255072-99@https.bugs.freebsd.org/bugzilla/> References: <bug-255072-99@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255072 --- Comment #32 from spell@itl.ua --- (In reply to Toomas Soome from comment #30) > just remind me, what version of freebsd is this, current? 12.3. Initially I started with 13.0 and noticed that visually its loader crashes the samely as 12.2's does (and later as 12.3 does), and I've stuck = with the 12.3. > So virtual 0xffffe000 is physical 0x00008000 Got it, thank you. > So, if the INT will write past 0x8000 + 0x1000, it will corrupt BTX; This never happens in my experiments (or goes seamlessly). Using V86_IO_BUF= FER always is successful. > if INT will write past end of bio_buffer, it will corrupt next variable i= n BSS. If no buffer overrun when using V86_IO_BUFFER (that is 4K large), how can it happen when using bio_buffer (that is 16K large) if all other conditions are the same? Also I am trying to decrypt the symptom that the crash occurs not in the sa= me point of loader run. Seems that the bio_buffer area is somehow used by BIOS concurrently with using it by v86int() (just to remind - the loader crashes only when AHCI mode set in BIOS settings), or the INT runs somehow differen= tly depending on IDE/AHCI mode. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-255072-99-vOn12ZHRMj>