Can't use USB keyboard during boot menu
Renato Botelho
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
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.
Chris Hedley
> On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley
> <freebsd...@chrishedley.com> wrote:
>>
>> 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...
Renato Botelho
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
Andriy Gapon
>> 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
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
Nope, UFS. I'll try to find another USB keyboard to test
--
Renato Botelho
John Baldwin
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
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
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
It still breaks:
error 1 lba 48
error 1 lba 1
No ZFS pools located, can't boot
-Brandon
John Baldwin
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
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
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
Brandon Gooch
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
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.
> 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
> On Tuesday 23 February 2010 7:59:58 pm Brandon Gooch wrote:
> > On Tue, Feb 23, 2010 at 10:40 PM, John Baldwin <j...@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 <j...@freebsd.org> wrote:
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 <m...@madpilot.net>
John Baldwin
What error code are you seeing, 1?
--
John Baldwin
Guido Falsi
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 <m...@madpilot.net>