Re: mail archive on freebsd.org
We were in the middle of a hardware upgrade. Things should be restored now. mcl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
mail archive on freebsd.org
Hey.. something is wrong with the web mailing-list archive : http://docs.freebsd.org/mail/current/ when I try to read individual messages, I see "The specified message cannot be accessed." Can someone with the access and know how look into the problem? -Phil. (sorry if this is the wrong list.. but it's the one that I'm subscribed to) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS boot problems with memory > 1MB
On Tue, Feb 23, 2010 at 10:40 PM, John Baldwin wrote:
> On Tuesday 23 February 2010 5:04:03 pm Brandon Gooch wrote:
>> On Tue, Feb 23, 2010 at 3:03 PM, John Baldwin wrote:
>> > On Tuesday 23 February 2010 3:36:19 pm Brandon Gooch wrote:
>> >> On Tue, Feb 23, 2010 at 1:01 PM, John Baldwin wrote:
>> >> > On Tuesday 23 February 2010 12:36:31 pm Brandon Gooch wrote:
>> >> >> On Tue, Feb 23, 2010 at 10:24 AM, John Baldwin
> wrote:
>> >> >> > On Tuesday 23 February 2010 10:28:49 am Brandon Gooch wrote:
>> >> >> >> On Tue, Feb 23, 2010 at 7:29 AM, Andriy Gapon
> wrote:
>> >> >> >> > on 23/02/2010 13:18 Renato Botelho said the following:
>> >> >> >> >> On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley
>> >> >> >> >> 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;
>> >> >
>> >> > + dm
Re: ZFS boot problems with memory > 1MB
On Tuesday 23 February 2010 5:04:03 pm Brandon Gooch wrote:
> On Tue, Feb 23, 2010 at 3:03 PM, John Baldwin wrote:
> > On Tuesday 23 February 2010 3:36:19 pm Brandon Gooch wrote:
> >> On Tue, Feb 23, 2010 at 1:01 PM, John Baldwin wrote:
> >> > On Tuesday 23 February 2010 12:36:31 pm Brandon Gooch wrote:
> >> >> On Tue, Feb 23, 2010 at 10:24 AM, John Baldwin
wrote:
> >> >> > On Tuesday 23 February 2010 10:28:49 am Brandon Gooch wrote:
> >> >> >> On Tue, Feb 23, 2010 at 7:29 AM, Andriy Gapon
wrote:
> >> >> >> > on 23/02/2010 13:18 Renato Botelho said the following:
> >> >> >> >> On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley
> >> >> >> >> 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, 0x1) -
> > __base);
> >> > +
> >> > bios_getmem();
> >> >
> >> > if (high_heap_size > 0) {
> >> > @@ -627,9 +630,6 @@
> >> >
Re: ZFS boot problems with memory > 1MB
On Tue, Feb 23, 2010 at 3:03 PM, John Baldwin wrote:
> On Tuesday 23 February 2010 3:36:19 pm Brandon Gooch wrote:
>> On Tue, Feb 23, 2010 at 1:01 PM, John Baldwin wrote:
>> > On Tuesday 23 February 2010 12:36:31 pm Brandon Gooch wrote:
>> >> On Tue, Feb 23, 2010 at 10:24 AM, John Baldwin wrote:
>> >> > On Tuesday 23 February 2010 10:28:49 am Brandon Gooch wrote:
>> >> >> On Tue, Feb 23, 2010 at 7:29 AM, Andriy Gapon wrote:
>> >> >> > on 23/02/2010 13:18 Renato Botelho said the following:
>> >> >> >> On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley
>> >> >> >> 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, 0x1) -
> __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, 0x1) -
> __base);
>> > - v86.ctl = V86_FLAGS;
>> > -
>> > dsk = malloc(sizeof(struct dsk));
>> > dsk->drive = *(uint8_t *)PTOV(ARGS);
>> > dsk->type = dsk->drive & DRV_HARD ? TYPE_AD :
Re: ZFS boot problems with memory > 1MB
On Tuesday 23 February 2010 3:36:19 pm Brandon Gooch wrote:
> On Tue, Feb 23, 2010 at 1:01 PM, John Baldwin wrote:
> > On Tuesday 23 February 2010 12:36:31 pm Brandon Gooch wrote:
> >> On Tue, Feb 23, 2010 at 10:24 AM, John Baldwin wrote:
> >> > On Tuesday 23 February 2010 10:28:49 am Brandon Gooch wrote:
> >> >> On Tue, Feb 23, 2010 at 7:29 AM, Andriy Gapon wrote:
> >> >> > on 23/02/2010 13:18 Renato Botelho said the following:
> >> >> >> On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley
> >> >> >> 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, 0x1) -
__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, 0x1) -
__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.ct
Re: ZFS boot problems with memory > 1MB
On Tue, Feb 23, 2010 at 1:01 PM, John Baldwin wrote:
> On Tuesday 23 February 2010 12:36:31 pm Brandon Gooch wrote:
>> On Tue, Feb 23, 2010 at 10:24 AM, John Baldwin wrote:
>> > On Tuesday 23 February 2010 10:28:49 am Brandon Gooch wrote:
>> >> On Tue, Feb 23, 2010 at 7:29 AM, Andriy Gapon wrote:
>> >> > on 23/02/2010 13:18 Renato Botelho said the following:
>> >> >> On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley
>> >> >> 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, 0x1) - __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, 0x1) - __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
-Bra
Re: ZFS boot problems with memory > 1MB
On Tuesday 23 February 2010 12:36:31 pm Brandon Gooch wrote:
> On Tue, Feb 23, 2010 at 10:24 AM, John Baldwin wrote:
> > On Tuesday 23 February 2010 10:28:49 am Brandon Gooch wrote:
> >> On Tue, Feb 23, 2010 at 7:29 AM, Andriy Gapon wrote:
> >> > on 23/02/2010 13:18 Renato Botelho said the following:
> >> >> On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley
> >> >> 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, 0x1) - __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, 0x1) - __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
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Virtualbox
On Tue, Feb 23, 2010 at 06:20:22PM +0200, Ian FREISLICH wrote: > Hi > > Has anyone managed to make Virtualbox work on 9-Current? Since > installing 3.1.2-OSE VMs, all brand new, abort on startup. > > The last part of the log seems pertinent: > > 00:00:15.481 !!Assertion Failed!! > 00:00:15.481 Expression: paPages[i].Phys != 0 && paPages[i].Phys != > NIL_RTHCPHYS && !(paPages[i].Phys & PAGE_OFFSET_MASK) > 00:00:15.481 Location : > /usr/ports/emulators/virtualbox-ose/work/VirtualBox-3.1.2_OSE/src/VBox/VMM/MMHyper.cpp(610) > int MMR3HyperMapPages(VM*, void*, RTR0PTR, size_t, const SUPPAGE*, const > char*, RTGCPTR64*) > 00:00:15.482 i=0x0 Phys= Heap > > Does anyone have any ideas? > Me not. Just FYI: ~> VBoxManage startvm WinXP --type sdl VirtualBox Command Line Management Interface Version 3.1.2_OSE (C) 2005-2009 Sun Microsystems, Inc. All rights reserved. Waiting for the remote session to open... Remote session has been successfully opened. ~> uname -a FreeBSD wep4035 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r202285: Thu Jan 14 19:04:21 CET 2010 r...@wep4035:/usr/obj/usr/src/sys/GENERIC amd64 ~> sysctl vm.pmap.pg_ps_enabled vm.pmap.pg_ps_enabled: 1 ~> cat /boot/loader.conf loader_logo="beastie" ichsmb_load="YES" snd_hda_load="YES" speaker_load="YES" i915_load="YES" linux_load="YES" vboxdrv_load="YES" The virtial machine was newly created and installed already on this CURRENT. 0.02$, Alexey. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Seeing the dreaded "ZFS: i/o error - all block copies unavailable" on 9.0-CURRENT
On Tue, Feb 23, 2010 at 8:20 AM, John Baldwin wrote: > On Thursday 18 February 2010 10:38:38 pm Chris wrote: > > > I'm seeing some difference in the bootloader output between using the > > > F12 workaround or not: > > > > > > F12 workaround mode: > > > > > > FreeBSD/i386 boot > > > Default: zroot:/boot/zfsloader > > > boot: status > > > config: > > > > > > NAME STATE > > > zrootONLINE > > >gpt/disk0 ONLINE > > > > > > > > > No F12 key pressed: > > > > > > FreeBSD/i386 boot > > > Default: zroot:/boot/kernel/kernel > > > config: > > > > > > NAME STATE > > > zrootONLINE > > > gpt/disk0 ONLINE > > > > > > > > > What's up with the differences between the Default boot setting? > > > > > > > Sorry for the spam but I'm seeing something else very interesting > > If I boot to Good Mode (F12) and break to the "boot:" prompt, the > > system boots if I type /boot/zfsloader. However, if I type > > /boot/kernel/kernel (as was seen in the Default setting when I didn't > > hit F12), I get a crash that looks like the following: > > - > > FreeBSD/i386 boot > > Default: zroot:/boot/zfsloader > > boot: /boot/kernel/kernel > > int=0006err= efl=00010882 eip=0020 > > eax=0018b070 ebx=ed7706bd ecx=c72e2ca8 edx= > > esi=0040 edi=000929d0 ebp=0009279c esp=9401 > > cs=0008 ds=0010 es=0010 fs=0010 gs=0010 ss=0010 > > cs:eip=ff ff ff ff ff ff ff ff 7f-00 00 00 00 00 00 00 00 > >00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 > > ss:esp=36 80 0d 07 90 00 00 01-e9 c4 fc ff ff aa ac 84 > > c0 0f 84 86 00 00 00 a8-80 74 f2 88 c5 b0 3d aa > > BTX halted > > - > > I'm not sure how well we support booting a kernel from boot2 anymore, much > less from zfsboot. Using /boot/loader (or /boot/zfsloader) is probably the > only tested (and realistically supported) case. Yeah, the last time I tried this it didn't work, but I didn't hunt down why. Matt > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ums fails to initialise correctly
On Mon, 22 Feb 2010, Chris Hedley wrote: I'm having a lot of problems getting the ums (USB mouse) driver to initialise the mouse correctly. Hmm. Just discovered something quite interesting. I decided to try a different mouse, so I've swiped the missus' for a while. It's also a Logitech, but an older model (and, incidentally, rather better made than my more expensive Revolution MX <_<). And it works without any bother. Perfectly happy switching to Windows and FreeBSD and back again, and I haven't been able to get it to not work yet. I guess the possibilities are: 1. My newer, problematic mouse (or rather its receiver) is a high-speed device, whilst the missus' old mouse has a low-speed one. This "shouldn't" cause conflicts since it works with Windows and Linux... but it does. 2. I used Uber Tools on Windows to reconfigure the behaviour of the mouse buttons and scroll wheel, which may be doing something undesirable. I'll fiddle about with it and see if I can repeat the not-workingness with her mouse, and just not use it if it's the culprit. 3. Maybe the Revolution MX just sucks in some random way that I don't know, and perhaps has some basic problem with adhering to the USB protocol. I'll write more when I find something conclusive. Or even inconclusive, for that matter. :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS boot problems with memory > 1MB
On Tue, Feb 23, 2010 at 10:24 AM, John Baldwin wrote:
> On Tuesday 23 February 2010 10:28:49 am Brandon Gooch wrote:
>> On Tue, Feb 23, 2010 at 7:29 AM, Andriy Gapon wrote:
>> > on 23/02/2010 13:18 Renato Botelho said the following:
>> >> On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley
>> >> 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.
-Brandon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ZFS boot problems with memory > 1MB
On Tuesday 23 February 2010 10:28:49 am Brandon Gooch wrote:
> On Tue, Feb 23, 2010 at 7:29 AM, Andriy Gapon wrote:
> > on 23/02/2010 13:18 Renato Botelho said the following:
> >> On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley
> >> 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
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Seeing the dreaded "ZFS: i/o error - all block copies unavailable" on 9.0-CURRENT
On Thursday 18 February 2010 10:38:38 pm Chris wrote: > > I'm seeing some difference in the bootloader output between using the > > F12 workaround or not: > > > > F12 workaround mode: > > > > FreeBSD/i386 boot > > Default: zroot:/boot/zfsloader > > boot: status > > config: > > > > NAME STATE > > zrootONLINE > >gpt/disk0 ONLINE > > > > > > No F12 key pressed: > > > > FreeBSD/i386 boot > > Default: zroot:/boot/kernel/kernel > > config: > > > > NAME STATE > > zrootONLINE > > gpt/disk0 ONLINE > > > > > > What's up with the differences between the Default boot setting? > > > > Sorry for the spam but I'm seeing something else very interesting > If I boot to Good Mode (F12) and break to the "boot:" prompt, the > system boots if I type /boot/zfsloader. However, if I type > /boot/kernel/kernel (as was seen in the Default setting when I didn't > hit F12), I get a crash that looks like the following: > - > FreeBSD/i386 boot > Default: zroot:/boot/zfsloader > boot: /boot/kernel/kernel > int=0006err= efl=00010882 eip=0020 > eax=0018b070 ebx=ed7706bd ecx=c72e2ca8 edx= > esi=0040 edi=000929d0 ebp=0009279c esp=9401 > cs=0008 ds=0010 es=0010 fs=0010 gs=0010 ss=0010 > cs:eip=ff ff ff ff ff ff ff ff 7f-00 00 00 00 00 00 00 00 >00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 > ss:esp=36 80 0d 07 90 00 00 01-e9 c4 fc ff ff aa ac 84 > c0 0f 84 86 00 00 00 a8-80 74 f2 88 c5 b0 3d aa > BTX halted > - I'm not sure how well we support booting a kernel from boot2 anymore, much less from zfsboot. Using /boot/loader (or /boot/zfsloader) is probably the only tested (and realistically supported) case. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ObsoleFiles.inc seems to be broken
Everytime I update my -current and run a make check-old, i got this: >>> Checking for old files /usr/include/sys/semaphore.h >>> Checking for old libraries >>> Checking for old directories /usr/share/examples/bc I remove both and if I update it again they back to the system. -- Renato Botelho ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Virtualbox
Hi Has anyone managed to make Virtualbox work on 9-Current? Since installing 3.1.2-OSE VMs, all brand new, abort on startup. The last part of the log seems pertinent: 00:00:15.481 !!Assertion Failed!! 00:00:15.481 Expression: paPages[i].Phys != 0 && paPages[i].Phys != NIL_RTHCPHYS && !(paPages[i].Phys & PAGE_OFFSET_MASK) 00:00:15.481 Location : /usr/ports/emulators/virtualbox-ose/work/VirtualBox-3.1.2_OSE/src/VBox/VMM/MMHyper.cpp(610) int MMR3HyperMapPages(VM*, void*, RTR0PTR, size_t, const SUPPAGE*, const char*, RTGCPTR64*) 00:00:15.482 i=0x0 Phys= Heap Does anyone have any ideas? Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Can't use USB keyboard during boot menu
On Tue, Feb 23, 2010 at 12:28 PM, Brandon Gooch
wrote:
> On Tue, Feb 23, 2010 at 7:29 AM, Andriy Gapon wrote:
>> on 23/02/2010 13:18 Renato Botelho said the following:
>>> On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley
>>> 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
>
> Renato, are you booting ZFS?
Nope, UFS. I'll try to find another USB keyboard to test
--
Renato Botelho
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Can't use USB keyboard during boot menu
On Tue, Feb 23, 2010 at 7:29 AM, Andriy Gapon wrote:
> on 23/02/2010 13:18 Renato Botelho said the following:
>> On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley
>> 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
Renato, are you booting ZFS?
-Brandon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Can't use USB keyboard during boot menu
on 23/02/2010 13:18 Renato Botelho said the following: > On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley > 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. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] SASL problems with spnego on 8.0-BETA4
The patch in question was committed a few month ago. I can only add that on my 8-STABLE machine the combination of cyrus/gssapi/openldap works fine. You have to check if output of ldd /usr/lib/libgssapi_krb5.so produce output like this: /usr/lib/libgssapi_krb5.so: libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x281ac000) libkrb5.so.10 => /usr/lib/libkrb5.so.10 (0x2830) libhx509.so.10 => /usr/lib/libhx509.so.10 (0x281b5000) libcrypto.so.6 => /lib/libcrypto.so.6 (0x2835b000) libroken.so.10 => /usr/lib/libroken.so.10 (0x281e9000) libasn1.so.10 => /usr/lib/libasn1.so.10 (0x284ae000) libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x281f8000) libcrypt.so.5 => /lib/libcrypt.so.5 (0x28527000) libc.so.7 => /lib/libc.so.7 (0x2808e000) On 23.02.2010, at 2:06, George Mamalakis wrote: > On 07/10/2009 07:38, John Marshall wrote: >> access with gssapi auth from a client succeeded. >> >> Perhaps George Mamalakis could test the _spnego case? > Guys, > > I am terribly sorry to tell you that I just now saw this conversation(!?!! 4 > months later !!!). This is due to the fact that at that time I was mainly > tracking the fbsd-stable list (my first email started in fbsd-stable list), > and since I use filters in thunderbird, I never got to see your emails in my > inbox...truly sorry once more!!! > > I don't know if Alexander's patch is still valid but from what I realize > -since I have built many systems based on fbsd-stable (with latest sources) > and I had to "hack" krb5-config in order to achieve correct behavior of > cyrus/gssapi/spnego/openldap- it hasn't yet been commited to fbsd8-stable > sources. If so, I will apply it on my machines and rerun my applications. > > Sorry again for the delay! > > -- > George Mamalakis > > IT Officer > Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), > MSc (Imperial College of London) > > Department of Electrical and Computer Engineering > Faculty of Engineering > Aristotle University of Thessaloniki > > phone number : +30 (2310) 994379 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Can't use USB keyboard during boot menu
On Tue, 23 Feb 2010, Renato Botelho wrote: On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley 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...___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Can't use USB keyboard during boot menu
On Mon, Feb 22, 2010 at 7:35 PM, Chris Hedley wrote: > On Mon, 22 Feb 2010, Renato Botelho wrote: > >> 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: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) >> pwr=ON >> ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) >> pwr=ON >> ugen2.1: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) >> pwr=ON >> ugen3.1: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) >> pwr=ON >> ugen4.1: at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) >> pwr=ON >> ugen3.2: at usbus3, cfg=0 md=HOST >> spd=FULL (12Mbps) pwr=SAVE >> ugen3.3: at usbus3, cfg=0 md=HOST spd=LOW >> (1.5Mbps) pwr=ON >> ugen3.4: 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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
