ZFS boot problems with memory > 1MB

Brandon Gooch jamesbrandongooch at gmail.com
Wed Feb 24 01:00:02 UTC 2010


On Tue, Feb 23, 2010 at 10:40 PM, John Baldwin <jhb at freebsd.org> wrote:
> On Tuesday 23 February 2010 5:04:03 pm Brandon Gooch wrote:
>> On Tue, Feb 23, 2010 at 3:03 PM, John Baldwin <jhb at freebsd.org> wrote:
>> > On Tuesday 23 February 2010 3:36:19 pm Brandon Gooch wrote:
>> >> On Tue, Feb 23, 2010 at 1:01 PM, John Baldwin <jhb at freebsd.org> wrote:
>> >> > On Tuesday 23 February 2010 12:36:31 pm Brandon Gooch wrote:
>> >> >> On Tue, Feb 23, 2010 at 10:24 AM, John Baldwin <jhb at freebsd.org>
> wrote:
>> >> >> > On Tuesday 23 February 2010 10:28:49 am Brandon Gooch wrote:
>> >> >> >> On Tue, Feb 23, 2010 at 7:29 AM, Andriy Gapon <avg at icyb.net.ua>
> wrote:
>> >> >> >> > on 23/02/2010 13:18 Renato Botelho said the following:
>> >> >> >> >> On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley
>> >> >> >> >> <freebsd-current at chrishedley.com> wrote:
>> >> >> >> > [snip]
>> >> >> >> >>> Do you have USB legacy support enabled in your BIOS?  I'm not
> sure
>> > if
>> >> >> >> >>> there's an option for the loader to use USB devices natively,
> but
>> > the BIOS's
>> >> >> >> >>> legacy option where it provides AT/PS2 emulation is probably
> the
>> > easiest way
>> >> >> >> >>> to get the keyboard working.
>> >> >> >> >>
>> >> >> >> >> Yes, I do, but it seems to be a regression on FreeBSD itself, I
> had
>> > this problem
>> >> >> >> >> in the past and I checked the same things i need to check in the
>> > past again and
>> >> >> >> >> everything is fine.
>> >> >> >> >
>> >> >> >> > A more precise way to state that would be "a regression in
> FreeBSD
>> > boot/loader".
>> >> >> >> > I think that you are referring to the issue that was fixed by
>> > r189017.
>> >> >> >> > It might be worthwhile investigating what was done in that
> revision
>> > and what
>> >> >> >> > happened in sys/boot code since then.
>> >> >> >> >
>> >> >> >> > One possibility is that your BIOS uses memory above 1MB for USB
>> > emulation, but
>> >> >> >> > doesn't mark that memory as used in system memory map.  In that
> case
>> > that memory
>> >> >> >> > could be overwritten by the loader.  If that's true then the
> blame
>> > is on the BIOS.
>> >> >> >> >  Alternatively, our code might be parsing the system memory map
>> > incorrectly.
>> >> >> >> > But I am just making wild guesses here.
>> >> >> >> >
>> >> >> >>
>> >> >> >> I don't know if it is at all related, but this commit has caused
>> >> >> >> problems for me booting at least one of my machines:
>> >> >> >>
>> >> >> >>
>> >
> http://svn.freebsd.org/viewvc/base/head/sys/boot/i386/zfsboot/zfsboot.c?r1=199714&r2=200309
>> >> >> >>
>> >> >> >> Commit message:
>> >> >> >>
>> >> >> >> Revision 200309 - (view) (annotate) - [select for diffs]
>> >> >> >> Modified Wed Dec 9 20:36:56 2009 UTC (2 months, 2 weeks ago) by jhb
>> >> >> >> File length: 24893 byte(s)
>> >> >> >> Diff to previous 199714
>> >> >> >> - Port bios_getmem() from libi386 to {gpt,}zfsboot() and use it to
>> >> >> >>   safely allocate a heap region above 1MB.  This enables
>> > {gpt,}zfsboot()
>> >> >> >>   to allocate much larger buffers than before.
>> >> >> >> - Use a larger buffer (1MB instead of 128K) for temporary ZFS
> buffers.
>> >  This
>> >> >> >>   allows more reliable reading of compressed files in a
> raidz/raidz2
>> > pool.
>> >> >> >>
>> >> >> >> Submitted by: Matt Reimer  mattjreimer of gmail
>> >> >> >> MFC after:    1 week
>> >> >> >
>> >> >> > Starting a new thread, which problems are you seeing with this
> change?
>> >  ZFS is
>> >> >> > a good bit more memory hungry than UFS, so it really needs to use
> high
>> > memory
>> >> >> > for its heap.  Also, I wonder if you still have problems if you use
> the
>> > older
>> >> >> > zfsboot with the newer zfsloader?  Finally, you need to use
> disklabel -
>> > B or
>> >> >> > some such to update the zfsboot bits for this change to take effect.
>> >> >> >
>> >> >> > --
>> >> >> > John Baldwin
>> >> >> >
>> >> >>
>> >> >> I filed a PR so it wouldn't fall through the cracks:
>> >> >>
>> >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=144234
>> >> >>
>> >> >> I guess I tried a combination of various revisions of bootstrap code
>> >> >> and loaders when I first encountered the issue. It was when I wrote a
>> >> >> recent gptzfsboot to the geom that I saw the symptoms:
>> >> >>
>> >> >> error 1 lba 48
>> >> >> error 1 lba 1
>> >> >> No ZFS pools located, can't boot
>> >> >>
>> >> >> I just wound up using sys/boot/i386/zfsboot/zfsboot.c revision 199714
>> >> >> to build a working gptzfsboot on another system and wrote that to the
>> >> >> disk to get the machine operational.
>> >> >
>> >> > Try this:
>> >> >
>> >> > Index: zfsboot.c
>> >> > ===================================================================
>> >> > --- zfsboot.c   (revision 204207)
>> >> > +++ zfsboot.c   (working copy)
>> >> > @@ -467,6 +467,7 @@
>> >> >  static inline void
>> >> >  putc(int c)
>> >> >  {
>> >> > +    v86.ctl = 0;
>> >> >     v86.addr = 0x10;
>> >> >     v86.eax = 0xe00 | (c & 0xff);
>> >> >     v86.ebx = 0x7;
>> >> > @@ -617,6 +618,8 @@
>> >> >     off_t off;
>> >> >     struct dsk *dsk;
>> >> >
>> >> > +    dmadat = (void *)(roundup2(__base + (int32_t)&_end, 0x10000) -
>> > __base);
>> >> > +
>> >> >     bios_getmem();
>> >> >
>> >> >     if (high_heap_size > 0) {
>> >> > @@ -627,9 +630,6 @@
>> >> >        heap_end = (char *) PTOV(bios_basemem);
>> >> >     }
>> >> >
>> >> > -    dmadat = (void *)(roundup2(__base + (int32_t)&_end, 0x10000) -
>> > __base);
>> >> > -    v86.ctl = V86_FLAGS;
>> >> > -
>> >> >     dsk = malloc(sizeof(struct dsk));
>> >> >     dsk->drive = *(uint8_t *)PTOV(ARGS);
>> >> >     dsk->type = dsk->drive & DRV_HARD ? TYPE_AD : TYPE_FD;
>> >> > @@ -1157,6 +1157,7 @@
>> >> >      * when no such key is pressed in reality. As far as I can tell,
>> >> >      * this only happens shortly after a reboot.
>> >> >      */
>> >> > +    v86.ctl = V86_FLAGS;
>> >> >     v86.addr = 0x16;
>> >> >     v86.eax = fn << 8;
>> >> >     v86int();
>> >> >
>> >> > --
>> >> > John Baldwin
>> >> >
>> >>
>> >> It still breaks:
>> >>
>> >> error 1 lba 48
>> >> error 1 lba 1
>> >> No ZFS pools located, can't boot
>> >
>> > Ok.  Can you add a printf to zfsboot.c to print out dsk->start in the case
>> > that you get an error?  error 1 means that the BIOS thinks it got a bad
>> > parameter, presumably in the disk packet.  If you wanted to be ambitious,
> just
>> > print out all of the fields in the packet when it fails.
>> >
>> > --
>> > John Baldwin
>> >
>>
>> Adding printf statements to drvread():
>>
>> printf("dsk->xxx: %u\n", dsk->xxx):
>>
>> Output:
>>
>> error 1 lba 48
>> dsk->drive: 0
>> dsk->type: 0
>> dsk->unit: 0
>> dsk->slice: 0
>> dsk->part: 0
>> dsk->init: 0
>> dsk->start: 978673664
>
> This value looks a bit high, do you have a partition that starts at an offset
> of about 466GB into the disk?
>
>> error 1 lba 1
>> dsk->drive: 0
>> dsk->type: 0
>> dsk->unit: 0
>> dsk->slice: 0
>> dsk->part: 0
>> dsk->init: 0
>> dsk->start: 0
>> No ZFS pools located, can't boot
>
> Sorry, I meant members of the 'packet' variable, though dsk->start is useful
> to have as well.
>
> --
> John Baldwin
>

Here it is (with some crazy dsk stuff included):

error 1 lba 48
packet.len: 16
packet.seg: 8192
packet.count: 16
packet.lba: 47
packet.off: 0
dsk->drive: 4294967295
dsk->slice: 4294967295
dsk->type: 4294967295
dsk->part: 4294967295
dsk->unit: 4294967295
dsk->init: 4294967295
dsk->start: 4294967295

error 1 lba 1
packet.len: 16
packet.seg: 8704
packet.count: 1
packet.lba: 1
packet.off: 0
dsk->drive: 4294967295
dsk->slice: 4294967295
dsk->type: 4294967295
dsk->part: 4294967295
dsk->unit: 4294967295
dsk->init: 4294967295
dsk->start: 4294967295

No ZFS pools located, can't boot

-Brandon


More information about the freebsd-current mailing list