Re: PostgreSQL performance on FreeBSD
> 28 jun 2014 kl. 12:21 skrev Konstantin Belousov : > >> On Sat, Jun 28, 2014 at 12:08:39PM +0200, Palle Girgensohn wrote: >> >> >>> 27 jun 2014 kl. 18:34 skrev Konstantin Belousov : >>> >>>> On Fri, Jun 27, 2014 at 10:57:53AM -0400, John Baldwin wrote: >>>>> On Friday, June 27, 2014 8:56:13 am Konstantin Belousov wrote: >>>>> Hi, >>>>> I did some measurements and hacks to see about the performance and >>>>> scalability of PostgreSQL 9.3 on FreeBSD, sponsored by The FreeBSD >>>>> Foundation. >>>>> >>>>> The results are described in https://kib.kiev.ua/kib/pgsql_perf.pdf. >>>>> The uncommitted patches, referenced in the article, are available as >>>>> https://kib.kiev.ua/kib/pig1.patch.txt >>>>> https://kib.kiev.ua/kib/patch-2 >>>> >>>> Did you run the same benchmark on the same hardware with any other OS's to >>>> compare results? >>> >>> No. >>> >>> FWIW, before the failing after the 30 clients is corrected, I do not >>> think it is much interesting to do such comparision. >> >> This is great work! >> >> Does anybody know how far back in FreeBSD versions using posix semaphore >> instead of sysv would make a difference? It seems we need a rather current >> version? 8.x did not support it at all, at some point at lest, and in 9 it >> was buggy. I could add he patch-2 to the port, but I reckon it needs a >> conditional based on FreeBSD version? > I recommend to add it as an option. The currently supported versions > of stable/9 and higher have new posix semaphores implementation. > The stable/8 also has posix semaphores, but there it is kernel-based > interface, I do not plan to evaluate it in any way. According to one source, posix semaphores uses O(N^2) file descriptors, where N is the number of connections. Do you know if this is true? (I'll try it, naturally, just checking). > > >> The clang bug should go upstreams, right? > I believe there is already some activity about it. I do not follow > clang development. Sounds good enough. > >> >> I have seen similar curves, presented by Greg Smith (PostgreSQL >> hacker) where he concluded that there is no point in running more >> than 50 concurrent connections. This was for Linux. In your measures, >> the knee is at 30. That's said, FreeBSD could and should do better, >> but probably there is a limit where there will be a knee in the graph >> and performance will drop. It should be more than 30, though, as you >> rightly commented. >> >> Do you any ideas to pursue this further apart from complicated >> rewrites like DragonFly? > I do. > > The scope of the current work was done to obtain understanding where do we > stay > and, if possible, evaluate ideas, possibly in the hackish way. I hope > and almost sure that this will be continued, but cannot provide any time > estimation. Great. If you need help testing, I might be able to help. Cheers, Palle ___ 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: PostgreSQL performance on FreeBSD
27 jun 2014 kl. 18:34 skrev Konstantin Belousov : > On Fri, Jun 27, 2014 at 10:57:53AM -0400, John Baldwin wrote: >> On Friday, June 27, 2014 8:56:13 am Konstantin Belousov wrote: >>> Hi, >>> I did some measurements and hacks to see about the performance and >>> scalability of PostgreSQL 9.3 on FreeBSD, sponsored by The FreeBSD >>> Foundation. >>> >>> The results are described in https://kib.kiev.ua/kib/pgsql_perf.pdf. >>> The uncommitted patches, referenced in the article, are available as >>> https://kib.kiev.ua/kib/pig1.patch.txt >>> https://kib.kiev.ua/kib/patch-2 >> >> Did you run the same benchmark on the same hardware with any other OS's to >> compare results? > > No. > > FWIW, before the failing after the 30 clients is corrected, I do not > think it is much interesting to do such comparision. This is great work! Does anybody know how far back in FreeBSD versions using posix semaphore instead of sysv would make a difference? It seems we need a rather current version? 8.x did not support it at all, at some point at lest, and in 9 it was buggy. I could add he patch-2 to the port, but I reckon it needs a conditional based on FreeBSD version? The clang bug should go upstreams, right? I have seen similar curves, presented by Greg Smith (PostgreSQL hacker) where he concluded that there is no point in running more than 50 concurrent connections. This was for Linux. In your measures, the knee is at 30. That's said, FreeBSD could and should do better, but probably there is a limit where there will be a knee in the graph and performance will drop. It should be more than 30, though, as you rightly commented. Do you any ideas to pursue this further apart from complicated rewrites like DragonFly? Palle ___ 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: gptzfsboot error using HP Smart Array P410i Controller
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... :)
>>>
>>> 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, Palle
>>>
>>> Christoph Hoffmann skrev:
>>>> 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.cFri Sep
>>>> 23 18:47:44 2011 *** *** 459,464 --- 459,465
>>>> heap_end = (char *) PTOV(bios_basemem); }
>>>>
>>>> +printf("Hello! I am a hack.\n"); dsk = malloc(sizeof(struct
>>>> dsk)); dsk->drive = *(uint8_t *)PTOV(ARGS); dsk->type = dsk->drive
>>>> & DRV_HARD ? TYPE_AD : TYPE_FD;
>>>>
>>>> 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 @ 2.53GHz QPI Speed: 5.8
>>>> GT/s.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Christoph
>>>>
>>>> On Oct 11, 2011, at 3:16 PM, Daniel Kalchev wrote:
>>>>> Has this issue been resolved somehow? Sane method to build
>>>>> gptzfsboot that will run on HP's P410i?
>>
>> Hi,
>>
>> This is still happening with 9.2-RELEASE on a HP DL 380 G5:
>
> Presumably 9.1?
>
>> gptzfsboot: error 1 lba 32
>> gptzfsboot: error 1 lba 1
>> gptzfsboot: No ZFS pools located, can't boot
>>
>> Andriy suggested the latest sys/boot/i386/common/edd.h@243024 from head,
>> but unfortunately it makes no difference.
>>
>> The printf hack above still works fine though.
>
> Do you have avg's most recent commit to edd.h to pack various structures?
> I'm
> not sure that made it into 9.1.
>
9.1, of course, sorry! :-)
Yes, I've built a fresh gptzfsboot using 9.1 + edd.h from head (with _packed
keywords added).
___
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: gptzfsboot error using HP Smart Array P410i Controller
-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 the hack - is it likely to believe that it will suddenly or
> sporadically fail?
>
> Cheers, Palle
>
> Christoph Hoffmann skrev:
>> 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
>> heap_end = (char *) PTOV(bios_basemem); }
>>
>> +printf("Hello! I am a hack.\n"); dsk = malloc(sizeof(struct
>> dsk)); dsk->drive = *(uint8_t *)PTOV(ARGS); dsk->type = dsk->drive
>> & DRV_HARD ? TYPE_AD : TYPE_FD;
>>
>> 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 @ 2.53GHz QPI Speed: 5.8
>> GT/s.
>>
>>
>> Regards,
>>
>> Christoph
>>
>>
>> On Oct 11, 2011, at 3:16 PM, Daniel Kalchev wrote:
>>
>>> Has this issue been resolved somehow? Sane method to build
>>> gptzfsboot that will run on HP's P410i?
Hi,
This is still happening with 9.2-RELEASE on a HP DL 380 G5:
gptzfsboot: error 1 lba 32
gptzfsboot: error 1 lba 1
gptzfsboot: No ZFS pools located, can't boot
Andriy suggested the latest sys/boot/i386/common/edd.h@243024 from head,
but unfortunately it makes no difference.
The printf hack above still works fine though.
Palle
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJQ7fXCAAoJEIhV+7FrxBJDKKsIALihEN7Ohc2w/d1bCHM0JkPg
JdLSQzKa96YBH29vhWbhLpxAd/x/Vkis0H5Kv96e2M9Bg6aiWGXZuChlyzEu8ZBQ
+q6hqXYcAQJEYzP2n9jWOCcYelYVmmtyLgKLtbx5GQeYkCdS98Icad9cOKWPZYDN
D2aMslLdCVS99RJrvMvtNj3X5roafRfQAXDoTXng/c1VpV1YoXmhHcLPVP2jGP8v
F29Vl5K/24d+CHA3HkUqi7WJ4xyodJSPOpjXtSyLs0mMEMPTY9E9kcp+OFj1JXh4
fnEK3wFIT1g7lpYQK9SF3bHJxu6o9sb67jKYynkMhP6jsCpLMkLMRWuseA22d+0=
=3gJo
-END PGP SIGNATURE-
___
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: gptzfsboot error using HP Smart Array P410i Controller
-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 hardware and use FreeBSD, could you please try > r243025? > > http://svnweb.freebsd.org/base?view=revision&revision=243025 > -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQ7doaAAoJEIhV+7FrxBJDRd0IAIaufFeA6TkvVv8ytwtoKyac M1d/181hq92PXjGKkqPsP7HB2z3c7Op9zMURh6yia0fUrP68ryw6YVrT22cksNAU W8WXvhXb80cGw9JKT6lerkqFezex8SInnxjKEiEs93ZRRS98nN2aasu+G5DUCaLK Fag/QUVJsTfriVpSy8RywKj3AVo2CN6qAoiT/wg+jg7Oqf/QkY9/0cxcrQtrjUJ6 2DTkHs6G3IfHUDmZGpfvlkBwJmbgc90dCC1F/BWsH2MTICcHxEZS8oVliaIgkCWp wSazAX0x0aYONnYVzIkeJvh/a1ahuVlAatlnuw0IcwPfc/h6wfYZgFIan40DUnY= =13n2 -END PGP SIGNATURE- ___ 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: gptzfsboot error using HP Smart Array P410i Controller
-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://svnweb.freebsd.org/base?view=revision&revision=243025 > -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQ7dlvAAoJEIhV+7FrxBJDyRIH/0ieSUwN9Ev8hsYIniCRtFMH 79QqQI0XmnASgNh+TXxQABOGUQ1SFUqi2sDsOv+lyPGGS5RIWIzy9GGr91+LlwJu bLexZqXCIzWjZwpJsIba2wF41Iwc7EDGy6cA28n+O3pfqfazewgvPWWIpcEJ/Rng sUTQOozZUhblNmvlcsdVpRw1i9QYhivy1d3Yj10AzDfioKXdvRT1d5//BmJ1aEh+ I9+JpG7c8geMLQ+z/mER8tbTg7/Sm+7qwAjM8bFg1lBdDKYryHC8d/nO4XFSE2IO DCrJRmoe8bormQWZVh4gP16phVm7cFWFXBn3JsRqJYYDrDMnm+LT4AXL/1v5BKY= =CBpm -END PGP SIGNATURE- ___ 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: gptzfsboot error using HP Smart Array P410i Controller
-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=243025 > -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQ7dc2AAoJEIhV+7FrxBJDttEIAMUsq/pmv9ZNPGQ7lk2vFVtk sP3TyqSj08q7aLJvURbCcOc20vUZp/TlirSrN8tL1h4O9HnPUdTQNIxlAN5ylrsi QkpDgK2kSM/ybOjWaFe0Olz3s/+47XJKfOEJsN8qLsmChnO7RUnjmJxz1HWCqWMf eNg7UnNOKZq0SyiZLDG8zF44Q0iU09voCFSAN/kXQl0YtxGbqt+HuI68w9cThRSr +jZmGYrnxHQxdqBagAoUU3mMLh9oGRhRLbfd5noXzJ3JWc+ljpjMt/3/YwZj5IcF BUydnCy9uiUepyAQSKFsJ97WsgeWwYxFOEWuWn/6ar3Shsoy5+9E/4d57AD9J5c= =AkUA -END PGP SIGNATURE- ___ 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: gptzfsboot error using HP Smart Array P410i Controller
-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.freebsd.org/base?view=revision&revision=243025 > -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQo3zPAAoJEIhV+7FrxBJD/gkH/R3n0mpEssT7bqmMH4lDcOTc MmYtQSxpBDRY2Ldvq/BmaRthtmg67K0Hq3iXzQOnUnmXDqQp2wJSUsCjHOto838e 6JpO9gVqxmVXmQWAMEhCt5n60RBhgrGdnIfGlOIZSTp+jiB5KAo8FHFBHCPoq/yB 2fcqOdraoKQXWij5TAnNnyfVl08E7VubL3zj/AMB2hcHSNnX3A5GxGOiCvLGLRnR 6xNt9T/Kyc0VF/G/AGYbbKcu91LcvSpcCje8VGvWkGZUgTblUUKfGmBEHE5X5Oz6 FCGP9fdwzIx3P3zRKVJqTnoxNYPJXIuy1YEitKPL5r3jA6GQAlFDKk7y6BX6Yvk= =gXAy -END PGP SIGNATURE- ___ 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: gptzfsboot error using HP Smart Array P410i Controller
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 (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, this fix should be in 9.0, so I don't have an explanation for why
>>> booting
>>> on 9.0 would still be broken.
>>
>>
>> Ok, that's odd. I tried 9.0, it does fail, and the printf actually makes it
>> work.
>
> Can you try editing sys/boot/i386/common/drv.c and adding some additional
> padding after
> the edd_params? Perhaps the BIOS is assuming it always gets the full thing
> even if
> we pass in a 1.1-sized structure. Just try putting a edd_params_v4 structure
> after the
> normal one.
Yes, I'll try that. It might take a couple of days, since I'm in the a quite
busy the next day or two, but I will check it out.
Cheers,
Palle
>
>> Palle
>>
>>>
>>>> Regards,
>>>>
>>>> Christoph
>>>>
>>>> Author: jhb
>>>> Date: Wed Nov 9 18:26:19 2011
>>>> New Revision: 227400
>>>> URL:
>>>> http://svn.freebsd.org/changeset/base/227400
>>>>
>>>> Log:
>>>> MFC 226748:
>>>> - Add a new header for the x86 boot code that defines various structures
>>>> and constants related to the BIOS Enhanced Disk Drive Specification.
>>>> - Use this header instead of magic numbers and various duplicate structure
>>>> definitions for doing I/O.
>>>> - Use an actual structure for the request to fetch drive parameters in
>>>> drvsize() rather than a gross hack of a char array with some magic
>>>> size. While here, change drvsize() to only pass the 1.1 version of
>>>> the structure and not request device path information. If we want
>>>> device path information you have to set the length of the device
>>>> path information as an input (along with probably checking the actual
>>>> EDD version to see which size one should use as the device path
>>>> information is variable-length). This fixes data smashing problems
>>>> from passing an EDD 3 structure to BIOSes supporting EDD 4.
>>>>
>>>> Approved by:re (kib)
>>>>
>>>> --
>>>> Christoph Hoffmann
>>>>
>>>> On Mar 1, 2012, at 10:39 PM, Palle Girgensohn wrote:
>>>>
>>>>> 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,
>>>>> Palle
>>>>>
>>>>> Christoph Hoffmann skrev:
>>>>>> 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.cFri Sep 23 18:47:44 2011
>>>>>> ***
>>>>>> *** 459,464
>>>>>> --- 459,465
>>>>>> heap_end = (char *) PTOV(bios_basemem);
>>>>>> }
>>>>>>
>>>>>> +printf("Hello! I am a hack.\n");
>>>>>> dsk = malloc(sizeof(struct dsk));
>>>>>> dsk->drive = *(uint8_t *)PTOV(ARGS);
>>>>>> dsk->type = dsk->drive & DRV_HARD ? TYPE_AD : TYPE_FD;
>>>>>>
>>>>>> 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:
>>
Re: gptzfsboot error using HP Smart Array P410i Controller
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.
>>
>> Maybe John could shade some light on it?
>
> Hmm, this fix should be in 9.0, so I don't have an explanation for why booting
> on 9.0 would still be broken.
Ok, that's odd. I tried 9.0, it does fail, and the printf actually makes it
work.
Palle
>
>> Regards,
>>
>> Christoph
>>
>> Author: jhb
>> Date: Wed Nov 9 18:26:19 2011
>> New Revision: 227400
>> URL:
>> http://svn.freebsd.org/changeset/base/227400
>>
>> Log:
>> MFC 226748:
>> - Add a new header for the x86 boot code that defines various structures
>>and constants related to the BIOS Enhanced Disk Drive Specification.
>> - Use this header instead of magic numbers and various duplicate structure
>>definitions for doing I/O.
>> - Use an actual structure for the request to fetch drive parameters in
>>drvsize() rather than a gross hack of a char array with some magic
>>size. While here, change drvsize() to only pass the 1.1 version of
>>the structure and not request device path information. If we want
>>device path information you have to set the length of the device
>>path information as an input (along with probably checking the actual
>>EDD version to see which size one should use as the device path
>>information is variable-length). This fixes data smashing problems
>>from passing an EDD 3 structure to BIOSes supporting EDD 4.
>>
>> Approved by:re (kib)
>>
>> --
>> Christoph Hoffmann
>>
>> On Mar 1, 2012, at 10:39 PM, Palle Girgensohn wrote:
>>
>>> 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,
>>> Palle
>>>
>>> Christoph Hoffmann skrev:
>>>> 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.cFri Sep 23 18:47:44 2011
>>>> ***
>>>> *** 459,464
>>>> --- 459,465
>>>>heap_end = (char *) PTOV(bios_basemem);
>>>> }
>>>>
>>>> +printf("Hello! I am a hack.\n");
>>>> dsk = malloc(sizeof(struct dsk));
>>>> dsk->drive = *(uint8_t *)PTOV(ARGS);
>>>> dsk->type = dsk->drive & DRV_HARD ? TYPE_AD : TYPE_FD;
>>>>
>>>> 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 @ 2.53GHz
>>>> QPI Speed: 5.8 GT/s.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Christoph
>>>>
>>>>
>>>> On Oct 11, 2011, at 3:16 PM, Daniel Kalchev wrote:
>>>>
>>>>> 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-current-unsubscr...@freebsd.org"
>>>>
>>>> ___
>>>> 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"
>>> ___
>>> 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"
>>
>>
>
> --
> 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: gptzfsboot error using HP Smart Array P410i Controller
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,
Palle
Christoph Hoffmann skrev:
> 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 Sep 23 18:47:44 2011
> ***
> *** 459,464
> --- 459,465
> heap_end = (char *) PTOV(bios_basemem);
> }
>
> + printf("Hello! I am a hack.\n");
> dsk = malloc(sizeof(struct dsk));
> dsk->drive = *(uint8_t *)PTOV(ARGS);
> dsk->type = dsk->drive & DRV_HARD ? TYPE_AD : TYPE_FD;
>
> 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 @ 2.53GHz
> QPI Speed: 5.8 GT/s.
>
>
> Regards,
>
> Christoph
>
>
> On Oct 11, 2011, at 3:16 PM, Daniel Kalchev wrote:
>
>> 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-current-unsubscr...@freebsd.org"
>
> ___
> 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"
___
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: Remote access to HP Proliant hardware available to fix the problem with failing booting 9.0 on ciss(4), HP SmartArray P410i
23 nov 2011 kl. 02:20 skrev Sean Bruno : > On Tue, 2011-11-22 at 14:59 -0800, Palle Girgensohn wrote: >> Hi, >> >> When installing 9.0 RC1 on our HP servers, we of course wanted to use gpt >> intead of fdisk. However, it doesn't work. >> >> First I tried gptzfsboot, it failed with an error (see this thread: >> http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026175.html) >> >> Second, I tried a standard gptboot, it just goes into a boot loop. >> >> Seriously, we have a couple of idle machines with ciss(4) and an iLO (for >> remote connections). If someone has the knowledge and time to try and fix >> the problems with ciss and gpt boot, we have the equipment for it. >> >> We tried with a standard vanilla zpool, no mirror or raid at all, on top of >> a ciss raid-5, and it failed with RC1. [trying RC2 now, but seems nothing is >> changed?]. >> >> Anyone up to the task of finding this culprit, we can let you into the >> machine remotely through the iLO. Please let me know. >> >> Best reagards >> Palle Girgensohn > > I just got done with an HP DL160G6 with a P410 raid-5 configuration in > the freebsd.org cluster. I definitely had to use RC2 due to some type > of disk issue. I suspect that > http://svnweb.freebsd.org/base?view=revision&revision=227400 fixed it. > > Sean > Thanks for the heads-up! Hoping for rc2! :-) Palle___ 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"
Remote access to HP Proliant hardware available to fix the problem with failing booting 9.0 on ciss(4), HP SmartArray P410i
Hi, When installing 9.0 RC1 on our HP servers, we of course wanted to use gpt intead of fdisk. However, it doesn't work. First I tried gptzfsboot, it failed with an error (see this thread: http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026175.html) Second, I tried a standard gptboot, it just goes into a boot loop. Seriously, we have a couple of idle machines with ciss(4) and an iLO (for remote connections). If someone has the knowledge and time to try and fix the problems with ciss and gpt boot, we have the equipment for it. We tried with a standard vanilla zpool, no mirror or raid at all, on top of a ciss raid-5, and it failed with RC1. [trying RC2 now, but seems nothing is changed?]. Anyone up to the task of finding this culprit, we can let you into the machine remotely through the iLO. Please let me know. Best reagards Palle Girgensohn girgen@FreeBSD.org___ 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 dump vinum volumes after upgrading
Greg Lehey wrote:
>
> On Tuesday, 21 March 2000 at 14:48:55 +0100, Palle Girgensohn wrote:
> > Hi!
> >
> > I'm having a strange problem after upgrading: There are no raw
> > devices created for vinum volumes.
>
> Indeed there are. You list them below. There are no longer any block
> devices.
>
>
> This was a block device.
>
...
>
> This is now a character device.
OK. Of course. Cool!
> You don't describe what dump has to say. I know that they put in a
> fix recently, but you don't say how old your system is.
The system is 4.0-STABLE, which is more or less 4.0-RELEASE right
now.
dump fails at the point were it is trying to convert the block
device listed in fstab to a raw device, by inserting a 'r' after
the last '/' in the pathname. This part of dump wasn't changed
since the initial import :)
in sbin/dump/main.c:546:
char *
rawname(cp)
char *cp;
{
static char rawbuf[MAXPATHLEN];
char *dp = strrchr(cp, '/');
if (dp == NULL)
return (NULL);
*dp = '\0';
(void)strncpy(rawbuf, cp, MAXPATHLEN - 1);
rawbuf[MAXPATHLEN-1] = '\0';
*dp = '/';
(void)strncat(rawbuf, "/r", MAXPATHLEN - 1 -
strlen(rawbuf));
(void)strncat(rawbuf, dp + 1, MAXPATHLEN - 1 -
strlen(rawbuf));
return (rawbuf);
}
So, here what dump says:
trumpet:vinum# dump 0af /dev/null /cluster1
DUMP: Date of this level 0 dump: Wed Mar 22 02:10:20 2000
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/vinum/rcluster1 (/cluster1) to /dev/null
DUMP: Cannot open /dev/vinum/rcluster1
which is rather expected.
My fstab has the line:
/dev/vinum/cluster1 /cluster1 ufs rw 2 2
Since you've enlighted me with the fact that there are only
character devices in vinum nowadays, my suggestion is putting a
symlink rfilesys->filesys in /dev/vinum for each filesystem, or
creating device nodes named rfilesys as well. This would make
dump(8) happy anyway.
Also, the manual pages (both vinum(4) vinum(8)) seem to be a bit
off here, since they mention both raw devices,
/dev/rvinum/rfilesys and /dev/vinum/rfilesys, none of which I
have (I do have /dev/rvinum/filesys, but they were probably made
under 3.4, right? Can I remove them?).
Oh, by the way, I love vinum. Thanks for all the hard work!
Cheers,
Palle
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: can't dump vinum volumes after upgrading
This fixes it for me. Is my installation faulty, or is this something that vinum fails to do when creating its devices? #! /bin/sh cd /dev/vinum for i in ../rvinum/*; do ln -s $i r`basename $i`; done /Palle To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: can't dump vinum volumes after upgrading
Hello again. I did some rtfm and src digging, it appears the listing I gave is correct; the raw devices are in the rvinum dircetory. Problem is, dump looks in vinum/r*. There seems that vinum introduces a bug here, since dump's rawname function replaces the last '/' in the device name with '/r'. In my 3.4 systems I have both rvinum and vinum/r* in my /dev directory. One solution is for vinum to create symlinks /dev/vinum/rplex -> /dev/rvinum/plex, to help dump find the raw device from the fstab entry. That's what I'm doing manually now to get my filesystems dumped. This should probably be handled by vinum somehow? /Palle To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
can't dump vinum volumes after upgrading
Hi! I'm having a strange problem after upgrading: There are no raw devices created for vinum volumes. This makes dump(8) puke. This is a 3.4 system: ls -laF /dev/vinum ... crwxr-xr-- 1 root wheel 91, 1 2 Jul 1999 rusr* drwxr-xr-x 2 root wheel 512 2 Jul 1999 rvol/ ... brwxr-xr-- 1 root wheel 25, 1 2 Jul 1999 usr* drwxr-xr-x 4 root wheel 512 2 Jul 1999 vol/ ... and here's a 4.0: crw-r- 1 root wheel 91, 0 21 Mar 13:40 usr drwxr-xr-x 11 root wheel 512 21 Mar 13:40 vol/ vinum makedev doesn't help. what gives? /Palle To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3 -> 4 when /usr is a vinum volume?
Greg Lehey wrote: > > [Format recovered--see http://www.lemis.com/email/email-format.html] > > On Saturday, 18 March 2000 at 3:34:38 +0100, Palle Girgensohn wrote: > > Hi! > > Please don't send messages one line per paragraph. It's a pain to > reformat. Yeah, I had had fiddled with the setting for a specific purpose, but forgot to set them back. Sorry about that! > > Following the instructions in UPDATING, when rebooting to single > > user mode, vinum wouldn't work since the kernel module was out of > > date - no surprise. > > Hmm. After updating, you should have had new klds as well. But > that's probably not your fault. Could you enter a PR about it, > please? Yes. It's a documentation bug, as has been pointed out by Daniel C. Sobral. > > So, I copied a fresh vinum.ko in there and tried again. This time, > > vinum loaded fine, but complained that it couldn't get the list from > > disk (or similiar). > > How similar? That statement doesn't really help very much. Vinum > produces error messages to help pinpoint problems. Unfortunately, I didn't write it down. I regret it. Here's briefly what happened: since 'start' didn't work, I tried to read the configurations off the disks one by one, which wasn't a very good idea, apparently, for since they weren't all started at once(?), some plexes were marked a faulty. I rebooted the kernel-3.x and started vinum with the old kld. It started and read all disks, but some were still marked faulty or flaky. I stopped and restarted the plexes/disks/subdisks quite a bit before got them all up again. It seems to me that vinum sometimes isn't quite logical about its decisions as to whether a disk/plex/sd is up or flaky. Is there a trick with the restarting sequence if a disk is marked flaky? I got the error 16(?) (device busy) a lot, and had to reboot again to get rid of them. After installing all klds and remaking the devices, I got the kernel-4.0 to read all the disks with the start command. > > 3-stable kernel, make first installed the make binary itself, and OK. Here's another documentation bug, imho. I missed moving the /etc/rc.conf.local away. make all depends on target upgrade_checks and it installs make if the test target fails. I think there should be a note to run make test before installworld. My make binary was blown away with no warning, and I was lucky to have another 3.x system left to fetch it from... > It looks like you shot yourself in the foot. Yeah, that's one way to put it :) > I'd have to find out what went wrong first. It looks as if it should > have worked modulo the problems installing the klds. Yep. I'm preparing a pr for documentation bugs. Thanks for your time. /Palle To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3 -> 4 when /usr is a vinum volume?
Alfred Perlstein wrote: > > Yowch, please wrap lines at 70 characters. :) Oops! Sorry about that. I had fiddled with the settings for a specific purpose, and forgot to set them back. :-/ > Read the loader page carefully and you should be able to boot 3.x > kernels with 3.x modules and 4.0 modules with a 4.0 kernel without > too much voodoo. Thanks for the tip. I'm not sure I read it close enough, for I set the module_path and it didn't help. Still, after installing all of the klds, I never really had to go back to the 3.x kernel, so it was ok anyway. The problem is of course that the UPDATING documentation lack info about installing the klds, and I didn't think about it. /Palle To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3 -> 4 when /usr is a vinum volume?
Warner Losh wrote: > > In message <[EMAIL PROTECTED]> "Daniel C. Sobral" writes: > : make buildworld > : make buildkernel > : make installkernel > : MAKEDEV > : reboot single user > : make -DNOINFO installworld > : make installworld > : > : As you see, the new klds don't get installed in the presently documented > : procedure. I have read a report wrt to linux compatibility too, but with > : vinum the problem is way bigger. > > They are installed as part of the installworld, which is too late. > It in docs/17518 now. /Palle To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
3 -> 4 when /usr is a vinum volume?
Hi! I'm having troubles updating a FreeBSD 3-stable system to current, since it has /usr as a vinum volume. I've just updated about a dozen machines without any problems, but none of them uses vinum. Following the instructions in UPDATING, when rebooting to single user mode, vinum wouldn't work since the kernel module was out of date - no surprise. So, I copied a fresh vinum.ko in there and tried again. This time, vinum loaded fine, but complained that it couldn't get the list from disk (or similiar). A 'vinum list' command would show nothing. So, I tried rebooting with the old 3-stable kernel. When makeing installworld running the 3-stable kernel, make first installed the make binary itself, and then could not do anything more, since the new libc was not in place, and the just installed make needed the new libc... odd? shall it really start by installing make? dunno how this happened? Anyway, what is a good strategy for upgrading a system where /usr is a vinum volume? Any tips, tricks or ideas (apart from moving /usr to a non-vinum volume and install onto that one). Thanks Palle To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: aha0 Invalid CCB or SG list
Hi Warner! Sorry to intrude, but I just want to check that I didn't miss any messages in this thread. Have you found anything that might be causing this problem? I think it's related to the 100% CPU utilization while writing full speed to both the ahc2940uw on pci and the 1542CP on isa. I realize this is not the easiest thing to debug; I had to sit and watch the screen for 90 minutes before it happened... Drop me a mail if you find anything. Thanks! /Palle Warner Losh wrote: > > In message <36d4b092.8b076...@partitur.se> Palle Girgensohn writes: > : I've seen three crashes in the last couple of weeks, with a server > : box that's been running stable as a rock for two years, at least. It > : has an adaptec 2940UW with six disks, and an adaptec 1542CP that's > : connected to a seagate travan tape driver. > > OK. This card is known to be good. At least I've not had any > problems with it. > > : It's running STABLE-3.1 from Feb 19 1999, and since the last > : upgrade, I've seen three crashes, all related to dumping to > : tape. Since I got no info on what happened, I decided to sit down > : with the machine, run a backup sequence to tape, and wait for it to > : possibly crash. After 90 minutes, I was about to give up when > : suddenly, poof: > : panic: aha0 Invalid CCB or SG list. > : > : So, it's probably the 1540 driver (or hardware)? > > Ah. OK. I'm not doing tape stuff on my machine. How fast is that > seagate tr-4 that you are doing? > > : Can anybody shed some light on what to do? Is it software? That's my > : guess, since the machine never ONCE has crashed until the upgrade to > : 3.x. I had one crash when running current form beginning of January > : (soon after moving to 3.x), and now theese three in a week. The 1540 > : has been in the machine for about six months. > > Chances are really good that this is software. The invalid ccb or sg > list is due to either a race condition or something taht corrupts > these things. > > : If there's anything I can do to help debug I'll do it, but device > : drivers are a little above my level of expertise. > > If you can wait a day or three, I might be able to find something that > will help. However, I don't have a tape drive right now to test it > with. I'll see what I can beg, borrow or steal. > > Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
panic: aha0 Invalid CCB or SG list
(Sorry for the crosspost, but I'd like to now if this is fixed in -current) Hi! I've seen three crashes in the last couple of weeks, with a server box that's been running stable as a rock for two years, at least. It has an adaptec 2940UW with six disks, and an adaptec 1542CP that's connected to a seagate travan tape driver. It's running STABLE-3.1 from Feb 19 1999, and since the last upgrade, I've seen three crashes, all related to dumping to tape. Since I got no info on what happened, I decided to sit down with the machine, run a backup sequence to tape, and wait for it to possibly crash. After 90 minutes, I was about to give up when suddenly, poof: panic: aha0 Invalid CCB or SG list. So, it's probably the 1540 driver (or hardware)? Can anybody shed some light on what to do? Is it software? That's my guess, since the machine never ONCE has crashed until the upgrade to 3.x. I had one crash when running current form beginning of January (soon after moving to 3.x), and now theese three in a week. The 1540 has been in the machine for about six months. Before starting the panicking backup, I spawned off a few logs: netstat -I de0 -w 5 and vmstat -p sa -p da -w 5 I'm not sure how to interpret them, but there's an excerpt at the end of this mail of the vmstat output (it stops in the middle of a row, when the crash occurred). The backups are made with amanda (see the ports collection), and uses gzip, hence the outbursts of cpu load. The netstat seems pretty uninteresting; quite normal. If there's anything I can do to help debug I'll do it, but device drivers are a little above my level of expertise. Thanks in advance! /Palle Here's a dmesg: Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.1-STABLE #0: Fri Feb 19 23:35:59 CET 1999 gir...@tb303.partitur.se:/usr/src/sys/compile/TRUMPET Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 198948269 Hz CPU: Pentium Pro (198.95-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x617 Stepping=7 Features=0xfbff real memory = 201326592 (196608K bytes) avail memory = 192790528 (188272K bytes) Preloaded elf kernel "kernel" at 0xf02b5000. Probing for devices on PCI bus 0: Correcting Natoma config for non-SMP chip0: rev 0x02 on pci0.0.0 chip1: rev 0x00 on pci0.7.0 ide_pci0: rev 0x00 on pci0.7.1 de0: rev 0x20 int a irq 12 on pci0.11.0 de0: SMC 9332BDT 21140A [10-100Mb/s] pass 2.0 de0: address 00:00:c0:27:eb:e9 vga0: rev 0x54 int a irq 9 on pci0.12.0 ahc0: rev 0x00 int a irq 11 on pci0.13.0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 not found sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A psm0 not found at 0x60 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdreset: error1: 0x0 wdreset: error1: 0x0 wdc0 not found at 0x1f0 aha0 at 0x330-0x333 irq 10 drq 7 on isa aha0: AHA-1542CP FW Rev. D.0 (ID=46) SCSI Host Adapter, SCSI ID 7, 16 CCBs vga0 at 0x3c0-0x3df maddr 0xa msize 131072 on isa npx0 on motherboard npx0: INT 16 interface Waiting 5 seconds for SCSI devices to settle de0: enabling 100baseTX port sa0 at aha0 bus 0 target 5 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 3.333MB/s transfers (3.333MHz, offset 8) da4 at ahc0 bus 0 target 4 lun 0 da4: Fixed Direct Access SCSI-2 device da4: 40.0MB/s transfers (20.0MHz, offset 8, 16bit), Tagged Queueing Enabled da4: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.0MB/s transfers (20.0MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 2049MB (4197405 512 byte sectors: 255H 63S/T 261C) changing root device to da0s1a da3 at ahc0 bus 0 target 3 lun 0 da3: Fixed Direct Access SCSI-2 device da3: 40.0MB/s transfers (20.0MHz, offset 8, 16bit), Tagged Queueing Enabled da3: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) da2 at ahc0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 40.0MB/s transfers (20.0MHz, offset 8, 16bit), Tagged Queueing Enabled da2: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.0MB/s transfers (20.0MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) WARNING: / was not properly dismounted ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated f
netd in free(): warning: junk pointer, too low to make sense.
Hi! I'm experiencing some strange errors with one of our workstations. I recently moved all of our workstations to 3.0 current as of 1998-12-18. Does any of this make any sense to anyone: trumpet:~>rlogin balalaika netd in free(): warning: junk pointer, too low to make sense. trumpet:~>telnet balalaika Trying 1.2.3.4... Connected to balalaika.partitur.se. Escape character is '^]'. inetd in free(): warning: junk pointer, too low to make sense. inetd in free(): warning: junk pointer, too high to make sense. inetd in free(): warning: junk pointer, too high to make sense. inetd in free(): warning: junk pointer, too high to make sense. inetd in free(): warning: junk pointer, too low to make sense. inetd in free(): warning: junk pointer, too high to make sense. inetd in free(): warning: junk pointer, too high to make sense. inetd in free(): warning: junk pointer, too high to make sense. inetd in free(): warning: junk pointer, too low to make sense. inetd in free(): warning: junk pointer, too high to make sense. inetd in free(): warning: junk pointer, too high to make sense. inetd in free(): warning: junk pointer, too high to make sense. inetd in free(): warning: junk pointer, too low to make sense. inetd in free(): warning: junk pointer, too high to make sense. inetd in free(): warning: junk pointer, too low to make sense. FreeBSD/i386 (balalaika.partitur.se) (ttyp2) login: username Ok... I get in... If I'm lucky. Sometimes not at all. Besides, it acts a little strange. For example, here's what newsyslog told me recently: newsyslog: preposterous process number: 77243 newsyslog: log not compressed because daemon not notified Restarting inetd fixes the problem with rlogin/telnet, but it is bound to come back within a day or so. My guess is that this started when we started using samba on the machine, for sharing some simple stuff to windows machines. The samba has probably not been recompiled since our elf transition (our server uses the same binaries, and serves them via nfs to the troubled machine), so there shouldn't be a problem. Anyway, I fetched the brand new 2.0 port of samba, but still have problems. I haven't modified the smb.conf, though. It seems at first that it is the inetd that has some kind of memory leak, but I really don't like that idea. Well... Any ideas appreciated. Get back if you need more input. uname -a: FreeBSD balalaika.partitur.se 3.0-CURRENT FreeBSD 3.0-CURRENT #1: Thu Jan 7 01:16:11 CET 1999 gir...@trumpet.partitur.se:/disk3/src/sys/compile/WORKSTATION i386 Oh, one more thing: There are five machines installed from the same build (built on the server, installed to all the boxes). The others work just fine. Regards, Palle To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
