10 jan 2013 kl. 18:15 skrev John Baldwin :
> On Wednesday, January 09, 2013 05:57:06 PM Palle Girgensohn wrote:
>> Palle Girgensohn skrev:
>>> Hi!
>>>
>>> This is still happening with FreeBSD 9.0-RELEASE, as I have just
>>> discovered. The hack works like a charm, but seems kind of odd... :)
>>
On Wednesday, January 09, 2013 05:57:06 PM Palle Girgensohn wrote:
> Palle Girgensohn skrev:
> > Hi!
> >
> > This is still happening with FreeBSD 9.0-RELEASE, as I have just
> > discovered. The hack works like a charm, but seems kind of odd... :)
> >
> > Any progress in getting a "real" fix into
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Palle Girgensohn skrev:
> Hi!
>
> This is still happening with FreeBSD 9.0-RELEASE, as I have just
> discovered. The hack works like a charm, but seems kind of odd... :)
>
> Any progress in getting a "real" fix into the repository? Any risks
> with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sorry, jumped the gun here... it booted first time, now it is back at
the same fail prompt...
gptzfsboot: error 1 lba 32
gptzfsboot: error 1 lba 1
gptzfsboot: No ZFS pools located, can't boot
Andriy Gapon skrev:
> Guys,
>
> if you still have the ha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This was for an HP DL380 G5, by the way.
I'll try it on a G6 later as well, I reckon the outcome will be similar.
Palle
Andriy Gapon skrev:
> Guys,
>
> if you still have the hardware and use FreeBSD, could you please try
> r243025?
>
> http://svnw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yes, this work like a charm. Super! Booted with no problems. Well done!
Palle
Andriy Gapon skrev:
> Guys,
>
> if you still have the hardware and use FreeBSD, could you please try
> r243025?
>
> http://svnweb.freebsd.org/base?view=revision&revision=
Hi Andriy,
I still have the HW and will test this next week.
Thanks,
Björn
Skickat från min iPhone
14 nov 2012 kl. 12:13 skrev Palle Girgensohn :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Thanks,
>
> We can chack it out, we are about to reinstall a machine. Migth be a HP
> DL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks,
We can chack it out, we are about to reinstall a machine. Migth be a HP
DL380 *G6* though, does that matter?
Andriy Gapon skrev:
> Guys,
>
> if you still have the hardware and use FreeBSD, could you please try
> r243025?
>
> http://svnweb.f
Guys,
if you still have the hardware and use FreeBSD, could you please try r243025?
http://svnweb.freebsd.org/base?view=revision&revision=243025
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/fr
5 mar 2012 kl. 22:16 skrev John Baldwin :
> On Monday, March 05, 2012 2:35:59 pm Palle Girgensohn wrote:
>>
>> 5 mar 2012 kl. 18:39 skrev John Baldwin :
>>
>>> On Saturday, March 03, 2012 7:06:14 pm Christoph Hoffmann wrote:
Hello,
I think this bug has been fix by John Baldwin (
On Monday, March 05, 2012 2:35:59 pm Palle Girgensohn wrote:
>
> 5 mar 2012 kl. 18:39 skrev John Baldwin :
>
> > On Saturday, March 03, 2012 7:06:14 pm Christoph Hoffmann wrote:
> >> Hello,
> >>
> >> I think this bug has been fix by John Baldwin (see below) after he found
> >> that HP
> >> impl
5 mar 2012 kl. 18:39 skrev John Baldwin :
> On Saturday, March 03, 2012 7:06:14 pm Christoph Hoffmann wrote:
>> Hello,
>>
>> I think this bug has been fix by John Baldwin (see below) after he found
>> that HP
>> implemented 'e09127r3 EDD-4 Hybrid MBR boot code annex' dated
>> 4 January 2010.
On Saturday, March 03, 2012 7:06:14 pm Christoph Hoffmann wrote:
> Hello,
>
> I think this bug has been fix by John Baldwin (see below) after he found that
> HP
> implemented 'e09127r3 EDD-4 Hybrid MBR boot code annex' dated
> 4 January 2010.
>
> Maybe John could shade some light on it?
Hmm, t
Hello,
I think this bug has been fix by John Baldwin (see below) after he found that HP
implemented 'e09127r3 EDD-4 Hybrid MBR boot code annex' dated
4 January 2010.
Maybe John could shade some light on it?
Regards,
Christoph
Author: jhb
Date: Wed Nov 9 18:26:19 2011
New Revision: 227400
URL
Hi!
This is still happening with FreeBSD 9.0-RELEASE, as I have just
discovered. The hack works like a charm, but seems kind of odd... :)
Any progress in getting a "real" fix into the repository? Any risks with
the hack - is it likely to believe that it will suddenly or sporadically
fail?
Cheers
On 13.10.11 00:33, Christoph Hoffmann wrote:
I am inclined to think that this is related to the way how we compile this code,
especially when run on the following particular processor:
1 Processor(s) detected, 4 total cores enabled, Hyperthreading is enabled
Proc 1: Intel(R) Xeon(R) CPU E5630
on 13/10/2011 00:33 Christoph Hoffmann said the following:
> Hello Daniel,
>
> Last time I checked up on the issue was on the 23rd of September,
> it was not fixed then.
> I was able to to boot from drive 0x80 after adding:
>
> *** zfsboot.c.origFri Sep 23 18:03:26 2011
> --- zfsboot.c Fri Se
Hello Daniel,
Last time I checked up on the issue was on the 23rd of September,
it was not fixed then.
I was able to to boot from drive 0x80 after adding:
*** zfsboot.c.orig Fri Sep 23 18:03:26 2011
--- zfsboot.c Fri Sep 23 18:47:44 2011
***
*** 459,464
--- 459,465
Has this issue been resolved somehow? Sane method to build gptzfsboot
that will run on HP's P410i?
Daniel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-c
Hello Everybody,
As per Dimitry request, please find set of gzip'ed zfsboot.s files (61223
bytes).
Due to size of the attachments which exceeded 200 KB, the original message
has been rejected.
Thank you very much indeed for your help and I am sorry of this spam.
Regards,
Christoph
--
Ch
On 2011-08-18 18:30, Christoph Hoffmann wrote:
...
Changing the order of execution in zfsboot.c main() function to
[…]
int
main(void)
{
[…]
bios_getmem();
if (high_heap_size> 0) {
[…]
bootinfo.bi_version = BOOTINFO_VERSION;
bootinfo.bi_size = sizeof(bootinfo);
bootinfo
On Thursday, August 18, 2011 1:49:18 pm Christoph Hoffmann wrote:
> John,
>
> Unfortunately not, as we is still need 4 additional instructions or some
sort of memory
> barrier [ like mb() in Tru64 :) ] .
Well, x86 CPUs generally don't need memory barriers assuming the compiler
hasn't done some
Hello,
Thank you very much for your information.
Even with both of them being implemented, I still have to re-order
the zfsboot.c main() function to get it working.
Regards,
Christoph
--
Christoph Hoffmann
On Aug 18, 2011, at 8:04 PM, Test Rat wrote:
> Christoph Hoffmann writes:
>
>> Hell
Christoph Hoffmann writes:
> Hello,
>
> The initial reboot followed the installation of ZFS-only version 5/28 system
> reports error:
>
> Attempting Boot From Hard Drive (C:)
> gptzfsboot: error 1 lba 32
> gptzfsboot: error 1 lba 1
> gptzfsboot: No ZFS pools located, can't boot
The bug may be un
John,
Unfortunately not, as we is still need 4 additional instructions or some sort
of memory
barrier [ like mb() in Tru64 :) ] .
Regards,
Christoph
--
Christoph Hoffmann
On Aug 18, 2011, at 7:10 PM, John Baldwin wrote:
> On Thursday, August 18, 2011 12:30:24 pm Christoph Hoffmann wrote:
>
On Thursday, August 18, 2011 12:30:24 pm Christoph Hoffmann wrote:
> Hello John,
>
> Thank you very much indeed for the hints.
>
> I am under the impression that we are facing a problem with synchronisation
> of CPU local caches. I also wasn't able to find any problem with memory
> allocation.
Hello John,
Thank you very much indeed for the hints.
I am under the impression that we are facing a problem with synchronisation
of CPU local caches. I also wasn't able to find any problem with memory
allocation.
This box is equipped with:
1 Processor(s) detected, 4 total cores enabled, Hype
On Tuesday, August 16, 2011 1:46:48 pm Christoph Hoffmann wrote:
> Setting high_heap_size to zero ends with an error:
>
> Attempting Boot From CD-ROM
> Attempting Boot From Hard Drive (C:)
> 474: high_heap_size=0x0; dsk=0x1a000; &bootinfo=0x8694
> malloc failure
Hmm, I am really at a loss for wha
Setting high_heap_size to zero ends with an error:
Attempting Boot From CD-ROM
Attempting Boot From Hard Drive (C:)
474: high_heap_size=0x0; dsk=0x1a000; &bootinfo=0x8694
malloc failure
--
Christoph Hoffmann
On Aug 16, 2011, at 4:41 PM, Christoph Hoffmann wrote:
> Hello John,
>
> First with pr
On Tuesday, August 16, 2011 10:41:50 am Christoph Hoffmann wrote:
> Hello John,
>
> First with printf() before
>dsk = malloc(sizeof(struct dsk));
>
> Attempting Boot From CD-ROM
> Attempting Boot From Hard Drive (C:)
> 464: high_heap_size=0x30; dsk=0x0; &bootinfo=0x8714<--- the ma
Hello John,
First with printf() before
dsk = malloc(sizeof(struct dsk));
Attempting Boot From CD-ROM
Attempting Boot From Hard Drive (C:)
464: high_heap_size=0x30; dsk=0x0; &bootinfo=0x8714<--- the malloc() is
next.
474: high_heap_size=0x30; dsk=0xdf325000; &bootinfo=0x8714
pr
On Tuesday, August 16, 2011 9:14:08 am Christoph Hoffmann wrote:
> Hello John,
>
> Thank you very much indeed for your reply.
>
> The pmbr.s passes the ARGS set to 0x900 to main() in zfsboot.c and
> *(uint8_t *)PTOV(ARGS)) is 0x80.
>
> In zfsboot.c main(), before the line
> bootinfo.bi_versio
Hello John,
Thank you very much indeed for your reply.
The pmbr.s passes the ARGS set to 0x900 to main() in zfsboot.c and
*(uint8_t *)PTOV(ARGS)) is 0x80.
In zfsboot.c main(), before the line
bootinfo.bi_version = BOOTINFO_VERSION;
gets executed we still keep the right value of the dsk->drive
On Friday, August 05, 2011 10:08:27 am Christoph Hoffmann wrote:
> Hello Everyone,
>
> Despite the BIOS information about the nonexistent floppy, the zfsboot.c
code
> will prevent to boot from the first HDD if a floppy is given as a first
available device.
>
> The drive 0x0 (floppy) will be pr
On Sunday, August 07, 2011 5:59:31 pm Xin LI wrote:
> On 08/01/11 06:07, Christoph Hoffmann wrote:
> > Hello,
> >
> > The initial reboot followed the installation of ZFS-only version 5/28
> > system reports error:
> >
> > Attempting Boot From Hard Drive (C:)
> > gptzfsboot: error 1 lba 32
> > gpt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/01/11 06:07, Christoph Hoffmann wrote:
> Hello,
>
> The initial reboot followed the installation of ZFS-only version 5/28
> system reports error:
>
> Attempting Boot From Hard Drive (C:)
> gptzfsboot: error 1 lba 32
> gptzfsboot: error 1 lb
Hello Everyone,
Despite the BIOS information about the nonexistent floppy, the zfsboot.c code
will prevent to boot from the first HDD if a floppy is given as a first
available device.
The drive 0x0 (floppy) will be probed before the code below and an error occurs:
[…]
gptzfsboot: error 1 lba 32
Hello John,
No, I and not using clang.
My problem persists even I apply the patch.
As a workaround I have to put OS on second LUN presented by the
P410i Controller.
Regards,
Christoph
--
Christoph Hoffmann
On Aug 5, 2011, at 1:37 PM, John Baldwin wrote:
> On Thursday, August 04, 2011 3:2
On Thursday, August 04, 2011 3:26:49 pm Christoph Hoffmann wrote:
> Hello Everyone,
>
> The system will successfully boot only if the OS installation is laying on
> the second drive or higher (0x81 and more).
Are you using clang? If so, you should try either using GCC or using this
patch with c
Hello Everyone,
The system will successfully boot only if the OS installation is laying on
the second drive or higher (0x81 and more).
Attempting Boot From CD-ROM
Attempting Boot From Hard Drive (C:)
40 matches
Mail list logo
