Date: Sun, 23 Jan 2022 19:15:57 +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-gYUdOzwt5k@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 #36 from spell@itl.ua --- Seems caught it. The crash occurs inside bd_edd_io(), wich calls BTX-owned int 31h which in = turn calls BIOS-owned int 13h, and it comes this last int is the one who do fail. The matter why this is so difficult to catch it is it crashes randomly. Wit= h no obvious differences in environment it may succeed or crash, approximately 9= 9/1. 11.2 loader crashes too, though very rarely. The rule is: more int 13h during loader run - more crash chance. By default 11.2 loader does not enter zfs probing stage and so requests only two or three int 13h per disk. With zfs probing (which is on by default in 12.3) the count of these requests is about a hundred, so the chance to cras= h is much bigger. Didn't try all the functions of int 13h but at least CMD_READ_LBA, CMD_READ= _CHS and one of CMD_CHECK_EDD, CMD_EXT_PARAM lead to the crash. These are my tests that proof this statement: 12.3 loader: I've added for(i=3D0; i<100; i++) with identical bd_edd_io() c= alls right after the original bd_edd_io() call, and the crash occurs inside of t= his bunch of calls (every time on different i value). 11.2 loader: The same with bd_int13probe(). The loader crashes every time on this or that i value. --=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-gYUdOzwt5k>