Discussion:
Can't use USB keyboard during boot menu
(too old to reply)
Renato Botelho
2010-02-22 16:35:06 UTC
Permalink
I've already had this problem in the past and seems it's back now.

I use a Sun Type 7 USB keyboard. When my box is booting, and
FreeBSD menu shows up, I cannot press any key to go for a
single boot for example.

ugen1.1: <UHCI root HUB VIA> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen0.1: <UHCI root HUB VIA> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen2.1: <UHCI root HUB VIA> at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen3.1: <UHCI root HUB VIA> at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen4.1: <EHCI root HUB VIA> at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON
ugen3.2: <product 0x100e vendor 0x0430> at usbus3, cfg=0 md=HOST
spd=FULL (12Mbps) pwr=SAVE
ugen3.3: <USB Mouse vendor 0x0566> at usbus3, cfg=0 md=HOST spd=LOW
(1.5Mbps) pwr=ON
ugen3.4: <Sun USB Keyboard vendor 0x0430> at usbus3, cfg=0 md=HOST
spd=FULL (12Mbps) pwr=ON

Please let me know if you need more data.

Thanks
--
Renato Botelho
Chris Hedley
2010-02-22 22:35:09 UTC
Permalink
Post by Renato Botelho
I've already had this problem in the past and seems it's back now.
I use a Sun Type 7 USB keyboard. When my box is booting, and
FreeBSD menu shows up, I cannot press any key to go for a
single boot for example.
ugen1.1: <UHCI root HUB VIA> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen0.1: <UHCI root HUB VIA> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen2.1: <UHCI root HUB VIA> at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen3.1: <UHCI root HUB VIA> at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen4.1: <EHCI root HUB VIA> at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON
ugen3.2: <product 0x100e vendor 0x0430> at usbus3, cfg=0 md=HOST
spd=FULL (12Mbps) pwr=SAVE
ugen3.3: <USB Mouse vendor 0x0566> at usbus3, cfg=0 md=HOST spd=LOW
(1.5Mbps) pwr=ON
ugen3.4: <Sun USB Keyboard vendor 0x0430> at usbus3, cfg=0 md=HOST
spd=FULL (12Mbps) pwr=ON
Please let me know if you need more data.
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.
Renato Botelho
2010-02-23 11:18:48 UTC
Permalink
On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley
Post by Renato Botelho
I've already had this problem in the past and seems it's back now.
I use a Sun Type 7 USB keyboard. When my box is booting, and
FreeBSD menu shows up, I cannot press any key to go for a
single boot for example.
ugen1.1: <UHCI root HUB VIA> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen0.1: <UHCI root HUB VIA> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen2.1: <UHCI root HUB VIA> at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen3.1: <UHCI root HUB VIA> at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen4.1: <EHCI root HUB VIA> at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON
ugen3.2: <product 0x100e vendor 0x0430> at usbus3, cfg=0 md=HOST
spd=FULL (12Mbps) pwr=SAVE
ugen3.3: <USB Mouse vendor 0x0566> at usbus3, cfg=0 md=HOST spd=LOW
(1.5Mbps) pwr=ON
ugen3.4: <Sun USB Keyboard vendor 0x0430> at usbus3, cfg=0 md=HOST
spd=FULL (12Mbps) pwr=ON
Please let me know if you need more data.
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.
--
Renato Botelho
Chris Hedley
2010-02-23 11:46:26 UTC
Permalink
Post by Renato Botelho
On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley
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.
I'm afraid in that case, this one's outside of my own somewhat limited
area of knowledge. AFAIK the loader uses the BIOS to process the keyboard
input, a wall I've been banging my own head against lately, so I'm a bit
surprised that it's stopped playing; but beyond that, I'm not sure.
Hopefully one of the more knowledgable types will wade in at this point...
Andriy Gapon
2010-02-23 13:29:05 UTC
Permalink
Post by Renato Botelho
On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley
[snip]
Post by Renato Botelho
Post by Chris Hedley
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.
--
Andriy Gapon
Brandon Gooch
2010-02-23 15:28:49 UTC
Permalink
Post by Andriy Gapon
Post by Renato Botelho
On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley
[snip]
Post by Renato Botelho
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

Renato, are you booting ZFS?

-Brandon
Renato Botelho
2010-02-23 15:47:22 UTC
Permalink
On Tue, Feb 23, 2010 at 12:28 PM, Brandon Gooch
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley
[snip]
Post by Renato Botelho
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
http://svn.freebsd.org/viewvc/base/head/sys/boot/i386/zfsboot/zfsboot.c?r1=199714&r2=200309
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
Renato, are you booting ZFS?
Nope, UFS. I'll try to find another USB keyboard to test
--
Renato Botelho
John Baldwin
2010-02-23 16:24:31 UTC
Permalink
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley
[snip]
Post by Renato Botelho
Post by Chris Hedley
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
http://svn.freebsd.org/viewvc/base/head/sys/boot/i386/zfsboot/zfsboot.c?r1=199714&r2=200309
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
Brandon Gooch
2010-02-23 17:36:31 UTC
Permalink
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley
[snip]
Post by Renato Botelho
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
http://svn.freebsd.org/viewvc/base/head/sys/boot/i386/zfsboot/zfsboot.c?r1=199714&r2=200309
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.

-Brandon
John Baldwin
2010-02-23 19:01:22 UTC
Permalink
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley
[snip]
Post by Renato Botelho
Post by Chris Hedley
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
http://svn.freebsd.org/viewvc/base/head/sys/boot/i386/zfsboot/zfsboot.c?r1=199714&r2=200309
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
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
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
Brandon Gooch
2010-02-23 20:36:19 UTC
Permalink
Post by John Baldwin
Post by Brandon Gooch
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley
[snip]
Post by Renato Botelho
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
http://svn.freebsd.org/viewvc/base/head/sys/boot/i386/zfsboot/zfsboot.c?r1=199714&r2=200309
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
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
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.
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

-Brandon
John Baldwin
2010-02-23 21:03:36 UTC
Permalink
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley
[snip]
Post by Renato Botelho
Post by Chris Hedley
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
http://svn.freebsd.org/viewvc/base/head/sys/boot/i386/zfsboot/zfsboot.c?r1=199714&r2=200309
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
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()
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
to allocate much larger buffers than before.
- Use a larger buffer (1MB instead of 128K) for temporary ZFS buffers.
This
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
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
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
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
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
some such to update the zfsboot bits for this change to take effect.
--
John Baldwin
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
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.
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
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
Brandon Gooch
2010-02-23 22:04:03 UTC
Permalink
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley
[snip]
Post by Renato Botelho
Do you have USB legacy support enabled in your BIOS?  I'm not sure
if
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
there's an option for the loader to use USB devices natively, but
the BIOS's
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
legacy option where it provides AT/PS2 emulation is probably the
easiest way
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
to get the keyboard working.
Yes, I do, but it seems to be a regression on FreeBSD itself, I had
this problem
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
in the past and I checked the same things i need to check in the
past again and
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
everything is fine.
A more precise way to state that would be "a regression in FreeBSD
boot/loader".
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
I think that you are referring to the issue that was fixed by
r189017.
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
It might be worthwhile investigating what was done in that revision
and what
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
happened in sys/boot code since then.
One possibility is that your BIOS uses memory above 1MB for USB
emulation, but
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
doesn't mark that memory as used in system memory map.  In that case
that memory
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
could be overwritten by the loader.  If that's true then the blame
is on the BIOS.
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
 Alternatively, our code might be parsing the system memory map
incorrectly.
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
But I am just making wild guesses here.
I don't know if it is at all related, but this commit has caused
http://svn.freebsd.org/viewvc/base/head/sys/boot/i386/zfsboot/zfsboot.c?r1=199714&r2=200309
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
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()
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
  to allocate much larger buffers than before.
- Use a larger buffer (1MB instead of 128K) for temporary ZFS buffers.
 This
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
  allows more reliable reading of compressed files in a raidz/raidz2
pool.
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
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
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
a good bit more memory hungry than UFS, so it really needs to use high
memory
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
for its heap.  Also, I wonder if you still have problems if you use the
older
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
zfsboot with the newer zfsloader?  Finally, you need to use disklabel -
B or
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
some such to update the zfsboot bits for this change to take effect.
--
John Baldwin
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
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.
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);
Post by Brandon Gooch
Post by John Baldwin
+
    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);
Post by Brandon Gooch
Post by John Baldwin
-    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
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
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

-Brandon
John Baldwin
2010-02-23 22:40:46 UTC
Permalink
Post by Brandon Gooch
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley
[snip]
Post by Renato Botelho
Post by Chris Hedley
Do you have USB legacy support enabled in your BIOS? I'm not
sure
Post by Brandon Gooch
if
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
Post by Chris Hedley
there's an option for the loader to use USB devices natively, but
the BIOS's
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
Post by Chris Hedley
legacy option where it provides AT/PS2 emulation is probably the
easiest way
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
Post by Chris Hedley
to get the keyboard working.
Yes, I do, but it seems to be a regression on FreeBSD itself, I had
this problem
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
in the past and I checked the same things i need to check in the
past again and
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
everything is fine.
A more precise way to state that would be "a regression in FreeBSD
boot/loader".
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
I think that you are referring to the issue that was fixed by
r189017.
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
It might be worthwhile investigating what was done in that revision
and what
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
happened in sys/boot code since then.
One possibility is that your BIOS uses memory above 1MB for USB
emulation, but
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
doesn't mark that memory as used in system memory map. In that
case
Post by Brandon Gooch
that memory
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
could be overwritten by the loader. If that's true then the
blame
Post by Brandon Gooch
is on the BIOS.
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Alternatively, our code might be parsing the system memory map
incorrectly.
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
But I am just making wild guesses here.
I don't know if it is at all related, but this commit has caused
http://svn.freebsd.org/viewvc/base/head/sys/boot/i386/zfsboot/zfsboot.c?r1=199714&r2=200309
Post by Brandon Gooch
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
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()
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
to allocate much larger buffers than before.
- Use a larger buffer (1MB instead of 128K) for temporary ZFS buffers.
This
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
allows more reliable reading of compressed files in a
raidz/raidz2
Post by Brandon Gooch
pool.
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
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
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
a good bit more memory hungry than UFS, so it really needs to use high
memory
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
for its heap. Also, I wonder if you still have problems if you use
the
Post by Brandon Gooch
older
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
zfsboot with the newer zfsloader? Finally, you need to use disklabel -
B or
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
some such to update the zfsboot bits for this change to take effect.
--
John Baldwin
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
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.
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);
Post by Brandon Gooch
Post by John Baldwin
+
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);
Post by Brandon Gooch
Post by John Baldwin
- 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
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
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?
Post by Brandon Gooch
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
Brandon Gooch
2010-02-24 00:59:58 UTC
Permalink
Post by Renato Botelho
Post by Brandon Gooch
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley
[snip]
Post by Renato Botelho
Do you have USB legacy support enabled in your BIOS?  I'm not
sure
Post by Brandon Gooch
if
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
there's an option for the loader to use USB devices natively,
but
Post by Brandon Gooch
the BIOS's
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
legacy option where it provides AT/PS2 emulation is probably
the
Post by Brandon Gooch
easiest way
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
to get the keyboard working.
Yes, I do, but it seems to be a regression on FreeBSD itself, I
had
Post by Brandon Gooch
this problem
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
in the past and I checked the same things i need to check in the
past again and
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
everything is fine.
A more precise way to state that would be "a regression in
FreeBSD
Post by Brandon Gooch
boot/loader".
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
I think that you are referring to the issue that was fixed by
r189017.
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
It might be worthwhile investigating what was done in that
revision
Post by Brandon Gooch
and what
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
happened in sys/boot code since then.
One possibility is that your BIOS uses memory above 1MB for USB
emulation, but
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
doesn't mark that memory as used in system memory map.  In that
case
Post by Brandon Gooch
that memory
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
could be overwritten by the loader.  If that's true then the
blame
Post by Brandon Gooch
is on the BIOS.
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
 Alternatively, our code might be parsing the system memory map
incorrectly.
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
But I am just making wild guesses here.
I don't know if it is at all related, but this commit has caused
http://svn.freebsd.org/viewvc/base/head/sys/boot/i386/zfsboot/zfsboot.c?r1=199714&r2=200309
Post by Brandon Gooch
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
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()
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
  to allocate much larger buffers than before.
- Use a larger buffer (1MB instead of 128K) for temporary ZFS
buffers.
Post by Brandon Gooch
 This
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
  allows more reliable reading of compressed files in a
raidz/raidz2
Post by Brandon Gooch
pool.
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Submitted by: Matt Reimer  mattjreimer of gmail
MFC after:    1 week
Starting a new thread, which problems are you seeing with this
change?
Post by Brandon Gooch
 ZFS is
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
a good bit more memory hungry than UFS, so it really needs to use
high
Post by Brandon Gooch
memory
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
for its heap.  Also, I wonder if you still have problems if you use
the
Post by Brandon Gooch
older
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
zfsboot with the newer zfsloader?  Finally, you need to use
disklabel -
Post by Brandon Gooch
B or
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
some such to update the zfsboot bits for this change to take effect.
--
John Baldwin
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
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.
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);
Post by Brandon Gooch
Post by John Baldwin
+
    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);
Post by Brandon Gooch
Post by John Baldwin
-    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
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
Post by Brandon Gooch
print out all of the fields in the packet when it fails.
--
John Baldwin
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?
Post by Brandon Gooch
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
John Baldwin
2010-02-24 14:55:27 UTC
Permalink
Post by Brandon Gooch
Post by Renato Botelho
Post by Brandon Gooch
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley
[snip]
Post by Renato Botelho
Post by Chris Hedley
Do you have USB legacy support enabled in your BIOS? I'm not
sure
Post by Brandon Gooch
if
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
Post by Chris Hedley
there's an option for the loader to use USB devices natively,
but
Post by Brandon Gooch
the BIOS's
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
Post by Chris Hedley
legacy option where it provides AT/PS2 emulation is probably
the
Post by Brandon Gooch
easiest way
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
Post by Chris Hedley
to get the keyboard working.
Yes, I do, but it seems to be a regression on FreeBSD itself, I
had
Post by Brandon Gooch
this problem
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
in the past and I checked the same things i need to check in the
past again and
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Post by Renato Botelho
everything is fine.
A more precise way to state that would be "a regression in
FreeBSD
Post by Brandon Gooch
boot/loader".
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
I think that you are referring to the issue that was fixed by
r189017.
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
It might be worthwhile investigating what was done in that
revision
Post by Brandon Gooch
and what
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
happened in sys/boot code since then.
One possibility is that your BIOS uses memory above 1MB for USB
emulation, but
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
doesn't mark that memory as used in system memory map. In that
case
Post by Brandon Gooch
that memory
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
could be overwritten by the loader. If that's true then the
blame
Post by Brandon Gooch
is on the BIOS.
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
Alternatively, our code might be parsing the system memory map
incorrectly.
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by Andriy Gapon
But I am just making wild guesses here.
I don't know if it is at all related, but this commit has caused
http://svn.freebsd.org/viewvc/base/head/sys/boot/i386/zfsboot/zfsboot.c?r1=199714&r2=200309
Post by Brandon Gooch
Post by Renato Botelho
Post by Brandon Gooch
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
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()
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
to allocate much larger buffers than before.
- Use a larger buffer (1MB instead of 128K) for temporary ZFS
buffers.
Post by Brandon Gooch
This
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
allows more reliable reading of compressed files in a
raidz/raidz2
Post by Brandon Gooch
pool.
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Submitted by: Matt Reimer mattjreimer of gmail
MFC after: 1 week
Starting a new thread, which problems are you seeing with this
change?
Post by Brandon Gooch
ZFS is
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
a good bit more memory hungry than UFS, so it really needs to use
high
Post by Brandon Gooch
memory
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
for its heap. Also, I wonder if you still have problems if you use
the
Post by Brandon Gooch
older
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
zfsboot with the newer zfsloader? Finally, you need to use
disklabel -
Post by Brandon Gooch
B or
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
some such to update the zfsboot bits for this change to take effect.
--
John Baldwin
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
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.
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);
Post by Brandon Gooch
Post by John Baldwin
+
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);
Post by Brandon Gooch
Post by John Baldwin
- 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
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,
Post by Brandon Gooch
Post by Renato Botelho
just
Post by Brandon Gooch
print out all of the fields in the packet when it fails.
--
John Baldwin
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?
Post by Brandon Gooch
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
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
These are all -1 now which looks wrong. The raw LBA being 47 instead of 48
would seem to indicate that that is the case though.
Post by Brandon Gooch
error 1 lba 1
packet.len: 16
packet.seg: 8704
packet.count: 1
packet.lba: 1
packet.off: 0
Odd that the lba here isn't 0.

Can you add some more printfs, maybe to probe_drive() to try narrow down how
many types that is being invoked and for which drive numbers?
--
John Baldwin
Guido Falsi
2010-04-09 11:01:23 UTC
Permalink
[...]
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
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
Post by Brandon Gooch
Post by John Baldwin
of about 466GB into the disk?
Post by Brandon Gooch
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
Post by Brandon Gooch
Post by John Baldwin
to have as well.
--
John Baldwin
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
These are all -1 now which looks wrong. The raw LBA being 47 instead of 48
would seem to indicate that that is the case though.
Post by Brandon Gooch
error 1 lba 1
packet.len: 16
packet.seg: 8704
packet.count: 1
packet.lba: 1
packet.off: 0
Odd that the lba here isn't 0.
Can you add some more printfs, maybe to probe_drive() to try narrow down how
many types that is being invoked and for which drive numbers?
Hi!

I'm seeing a very similar (perhaps the same) problem on a server I'm
trying to configure.

Is there any news about this issue?

This server is an HP DL360G6 server. Unluckily it has a smartarray thing
on it, the disk are behind it.

I wanted to configure a 6 drive raidz2 with the driver
present(configured as stand alone raid0 units, this is as near you can
go to have the smartarray give direct access to the drive to the
system, I know this is not optimal.)

After following the RootOnZFS instructions after boot the system gives
me the same symptoms the parent gets. Old gptzfsboot is not an option
here. It fails to malloc. I imagine 128K heap is not enough for my
setup.

I tried adding some more printfs but it outputs really a lot of data.
especially from drive_probe(). I see it cycling through the drives and
reading various addresses, what surprises me is it gets very high LBA
numbers. For example the last try(which remains on screen) looks like
this:

packet.len = 16
packet.count = 16
packet.off = 0
packet.seg = 8192
packet.lba = 1716867670
dsk->drive = 133
dsk->type = 0
dsk->unit = 5
dsk->slice = 0
dsk->part = 0
dsk->init = 0
dsk->start = 1716867430

Hope this information helps.

I will need some guidance to tinker zfsboot.c code any more tha this :(

This is a new machine I'm trying to configure. At present it's available
for any experiment.

At some time I will have to make it work anyway(even resorting to an UFS
/boot ior similar) but I have some time to experiment with it.

So I'm available for any further help or testing needed.

Thank you in advance for any help!
--
Guido Falsi <***@madpilot.net>
John Baldwin
2010-04-09 12:39:58 UTC
Permalink
Post by Guido Falsi
[...]
Post by John Baldwin
Post by Brandon Gooch
Post by John Baldwin
Post by Brandon Gooch
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
Post by Brandon Gooch
Post by John Baldwin
of about 466GB into the disk?
Post by Brandon Gooch
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
Post by Brandon Gooch
Post by John Baldwin
to have as well.
--
John Baldwin
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
These are all -1 now which looks wrong. The raw LBA being 47 instead of 48
would seem to indicate that that is the case though.
Post by Brandon Gooch
error 1 lba 1
packet.len: 16
packet.seg: 8704
packet.count: 1
packet.lba: 1
packet.off: 0
Odd that the lba here isn't 0.
Can you add some more printfs, maybe to probe_drive() to try narrow down how
many types that is being invoked and for which drive numbers?
Hi!
I'm seeing a very similar (perhaps the same) problem on a server I'm
trying to configure.
Is there any news about this issue?
This server is an HP DL360G6 server. Unluckily it has a smartarray thing
on it, the disk are behind it.
I wanted to configure a 6 drive raidz2 with the driver
present(configured as stand alone raid0 units, this is as near you can
go to have the smartarray give direct access to the drive to the
system, I know this is not optimal.)
After following the RootOnZFS instructions after boot the system gives
me the same symptoms the parent gets. Old gptzfsboot is not an option
here. It fails to malloc. I imagine 128K heap is not enough for my
setup.
I tried adding some more printfs but it outputs really a lot of data.
especially from drive_probe(). I see it cycling through the drives and
reading various addresses, what surprises me is it gets very high LBA
numbers. For example the last try(which remains on screen) looks like
packet.len = 16
packet.count = 16
packet.off = 0
packet.seg = 8192
packet.lba = 1716867670
dsk->drive = 133
dsk->type = 0
dsk->unit = 5
dsk->slice = 0
dsk->part = 0
dsk->init = 0
dsk->start = 1716867430
Hope this information helps.
What error code are you seeing, 1?
--
John Baldwin
Guido Falsi
2010-04-09 13:15:35 UTC
Permalink
Post by John Baldwin
Post by Guido Falsi
Hi!
I'm seeing a very similar (perhaps the same) problem on a server I'm
trying to configure.
Is there any news about this issue?
This server is an HP DL360G6 server. Unluckily it has a smartarray thing
on it, the disk are behind it.
I wanted to configure a 6 drive raidz2 with the driver
present(configured as stand alone raid0 units, this is as near you can
go to have the smartarray give direct access to the drive to the
system, I know this is not optimal.)
After following the RootOnZFS instructions after boot the system gives
me the same symptoms the parent gets. Old gptzfsboot is not an option
here. It fails to malloc. I imagine 128K heap is not enough for my
setup.
I tried adding some more printfs but it outputs really a lot of data.
especially from drive_probe(). I see it cycling through the drives and
reading various addresses, what surprises me is it gets very high LBA
numbers. For example the last try(which remains on screen) looks like
packet.len = 16
packet.count = 16
packet.off = 0
packet.seg = 8192
packet.lba = 1716867670
dsk->drive = 133
dsk->type = 0
dsk->unit = 5
dsk->slice = 0
dsk->part = 0
dsk->init = 0
dsk->start = 1716867430
Hope this information helps.
What error code are you seeing, 1?
Yes, exactly 1. With LBAs 1 or 32 reported in the error code(not the
additional printfs I added).

The error appears 8 times. Which is strange since the system has 6
disks, but 8 bays.
--
Guido Falsi <***@madpilot.net>
Loading...