Date: Wed, 22 May 2013 12:49:58 +1000 From: Lawrence Stewart <lstewart@freebsd.org> To: freebsd-hackers@freebsd.org Cc: dim@FreeBSD.org, avg@freebsd.org Subject: zfsloader triggering reset when interacting with v86int() Message-ID: <519C3256.7020409@freebsd.org>
next in thread | raw e-mail | index | archive | help
Hi all, I have an ageing Toshiba Portege R600 laptop (Intel ULV SU9400 1.4GHz Core2 CPU, 3GB RAM) running the latest v3.2 BIOS. I recently stuck a new Samsung 840 Pro 256GB SSD into it and decided to do my usual trick of dual booting Windows 7 and FreeBSD-on-ZFS-root. Windows 7 won't boot from a GPT scheme without a (U)EFI BIOS, so I had to use MBR + BSD labels for FreeBSD which I've never done before with ZFS. I followed the guide at [1] using the FreeBSD head r250260 snapshot from [2]. Rebooting into my newly configured FreeBSD slice from the boot0 F3 option, I'd see zfsloader start running and then the machine would reset. The last line flashed up on screen before the reset was something like "BIOS drive C:". With Andriy's (avg@) help, I went digging and traced the problem to zfsloader attempting to probe "disk0:" (floppy drive, though the machine doesn't have one physically). The code call path looks roughly like this with some functions omitted in the middle related to bios disk strategy. zfs_probe_dev -> open -> disk_open -> ptable_open -> ptblread -> <strategy stuff> -> bd_read -> bd_io -> bd_chs_io -> v86int() -> BOOM Turns out putting a simple printf above the call to v86int() resolved the problem and the system would progress to a successful boot. On a whim, I also tested adding an mfence above the call which also allowed the boot to complete successfully. Andriy also suggested I test his patch at [3] (applied to libi386/biosmem.c) which I did, but it did not fix the reset. After discussing further on IRC with Andriy (avg@) and Dimitry (dim@), it looked more like a case of BIOS-behaving-badly, so I went hunting and discovered that if I disabled "USB Floppy Emulation" (the only BIOS option related to floppies; defaults to enabled), the standard unmolested zfsloader would work fine. Re-enabling "USB Floppy Emulation" reliably triggers the zfsloader reset unless running my tweaked code. Two things fall out from my trip down this rabbit hole: 1. My BIOS is doing something nasty and/or stupid and I know how to work around it. Yay for me (although I should note that I was successfully running the regular non-ZFS loader previously without encountering this problem). 2. It would probably be sensible to avoid probing drives which have no possibility of being a ZFS candidate to minimise the chances of tickling BIOS bugs like the one I found. Andriy suggested only probing drives of a minimum size (128MB is mentioned at [4]). The problem is that to know the size of a disk you have to open it, and the open code path is what triggers the reset. I'm in well over my head here so I'm interested to hear thoughts on point 2 and/or any other theories about possible FreeBSD causes of the reset I'm seeing on the off chance my BIOS isn't actually at fault. Willing to test ideas/patches. Cheers, Lawrence [1] https://wiki.freebsd.org/RootOnZFS/ZFSBootPartition [2] http://mirror.aarnet.edu.au/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/10.0/FreeBSD-10.0-CURRENT-amd64-20130505-r250260-release.iso [3] http://thread.gmane.org/gmane.os.freebsd.current/143966/focus=148879 [4] http://docs.oracle.com/cd/E19253-01/819-5461/setup-1/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?519C3256.7020409>