Re: usb problems on HP DL980G7
On Friday 11 May 2012 02:54:19 John wrote: > Hi Folks, > >We've been trying to bring freebsd up on a hp dl980g7 for awhile. > Due to usb issues, we finally installed onto a revo card and > installed it into the 980. The system consistently puts out the > following messages: > > usbd_ctrl_transfer_setup: could not setup default USB transfer > usb_alloc_device: set address 2 failed (USB_ERR_NOMEM, ignored) > usbd_ctrl_transfer_setup: could not setup default USB transfer > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_NOMEM usbd_ctrl_transfer_setup: could not setup default USB > transfer > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_NOMEM, ignored) > usbd_ctrl_transfer_setup: could not setup default USB transfer > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_NOMEM usbd_ctrl_transfer_setup: could not setup default USB > transfer > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_NOMEM, ignored) > usbd_ctrl_transfer_setup: could not setup default USB transfer > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_NOMEM ugen0.2: at usbus0 (disconnected) > uhub_reattach_port: could not allocate new device > >From dmesg: > > pci0: at device 20.0 (no driver > attached) pcib12: at device 28.0 on pci0 > pci3: on pcib12 > pcib13: at device 28.4 on pci0 > pci2: on pcib13 > pci2: at device 0.0 (no driver attached) > pci2: at device 0.2 (no driver attached) > uhci0: port 0x3c00-0x3c1f irq 17 at device > 0.4 on pci2 usbus0 on uhci0 > uhci1: port 0x1000-0x101f irq > 20 at device 29.0 on pci0 device_attach: uhci1 attach returned 12 > uhci1: port 0x1020-0x103f irq > 23 at device 29.1 on pci0 device_attach: uhci1 attach returned 12 > uhci1: port 0x1040-0x105f irq > 22 at device 29.2 on pci0 device_attach: uhci1 attach returned 12 > uhci1: port 0x1060-0x107f irq > 23 at device 29.3 on pci0 device_attach: uhci1 attach returned 12 > ehci0: mem > 0xa030-0xa03003ff irq 20 at device 29.7 on pci0 device_attach: ehci0 > attach returned 12 > >Current - 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r235137M > >Nothing connected to usb on this systems works. > >Full dmesg is here: > http://people.freebsd.org/~jwd/dl980g7/dmesg.boot.html > >Any help is appreciated. Hi, If you compile a kernel with options USB_DEBUG, there are some tunables under hw.usb which can set various USB related delays. Try to double all USB sysctls having the keyword "delay". --HPS ___ 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"
[CFT] SMP/i386 suspend/resume
Hi I've been working on suspend/resume for SMP/i386 for a week and created patches against CURRENT, RELENG_9 and RELENG_8 available at: http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-CURRENT-20120511.diff http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_9-20120511.diff http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_8-20120511.diff A lot of portion of the patches was ported from amd64. Testing on Thinkpad X60 (Core Duo T2300), so far so good :) I'll commit them against CURRENT hopefully next week. Thanks and have fun! ___ 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: The current libc/locale/toupper.c is mistaken
Hi,
I'm sorry. I forgot to attach a file.
Regards,
Kohji Okuno
> Hi David,
>
> From: David Chisnall
>
>> If you have a test case, I can commit it to the libc++ test suite.
>>
>> David
>
> I attached my test source.
> This test program shoud output as below.
>
> towupper_l
> 0049, 0049
> 0131, 0049
> 0130, 0130
> 0069, 0049
>
> towlower_l
> 0049, 0069
> 0131, 0131
> 0130, 0069
> 0069, 0069
>
> But, when I use original toupper.c, this proguram output as below.
>
> towupper_l
> 0049, 0049
> 0131, 0131
> 0130, 0069
> 0069, 0049
>
> towlower_l
> 0049, 0069
> 0131, 0131
> 0130, 0069
> 0069, 0069
>
> Regards,
> Kohji Okuno
>
>>
>> On 10 May 2012, at 21:42, Kohji Okuno wrote:
>>
>>> Hi Eric,
>>>
I'm left wondering how this was not caught by the libc++ test
suite. The current toupper.c shouldn't pass
http://llvm.org/svn/llvm-project/libcxx/trunk/test/localization/locales/locale.convenience/conversions/conversions.character/toupper.pass.cpp
>>>
>>> This test suite checks only popular characters.
>>> __mapupper_ext is used in case of special characters.
>>>
>>> For example, Turkish 'i' (0x0131) should convert 'I' (0x49).
>>>
>>> Regards,
>>> Kohji Okuno
>>>
>>>
Den 10/05/2012 kl. 12.03 skrev Dimitry Andric:
> On 2012-05-10 11:02, Kohji Okuno wrote:
>> I think that libc/locale/toupper.c is mistaken.
>> Could you check it?
>>
>> @@ -51,7 +51,7 @@ ___toupper_l(c, l)
>> {
>> size_t lim;
>> FIX_LOCALE(l);
>> - _RuneRange *rr = &XLOCALE_CTYPE(l)->runes->__maplower_ext;
>> + _RuneRange *rr = &XLOCALE_CTYPE(l)->runes->__mapupper_ext;
>> _RuneEntry *base, *re;
>>
>> if (c < 0 || c == EOF)
>
> Yes, this definitely looks like a copy/paste error, introduced here:
>
> http://svnweb.freebsd.org/base/head/lib/libc/locale/toupper.c?r1=165903&r2=227753
>
> I'll commit the fix tonight (CEST), if David isn't faster than me. :)
I'm left wondering how this was not caught by the libc++ test suite. The
current toupper.c shouldn't pass
http://llvm.org/svn/llvm-project/libcxx/trunk/test/localization/locales/locale.convenience/conversions/conversions.character/toupper.pass.cpp
Thanks,
Erik___
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"
#include
#include
#include
#include
#include
int
main()
{
int i;
wint_t test[] = {0x0049, 0x0131, 0x0130, 0x0069};
wint_t ret;
locale_t x;
x = newlocale(0x1f, "tr_TR", NULL);
printf("towupper_l\n");
for (i = 0; i < sizeof(test)/sizeof(wint_t); i++) {
ret = towupper_l(test[i], x);
printf("%04x, %04x\n", test[i], ret);
}
printf("\n");
printf("towlower_l\n");
for (i = 0; i < sizeof(test)/sizeof(wint_t); i++) {
ret = towlower_l(test[i], x);
printf("%04x, %04x\n", test[i], ret);
}
exit(0);
}
___
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: The current libc/locale/toupper.c is mistaken
Hi David,
From: David Chisnall
> If you have a test case, I can commit it to the libc++ test suite.
>
> David
I attached my test source.
This test program shoud output as below.
towupper_l
0049, 0049
0131, 0049
0130, 0130
0069, 0049
towlower_l
0049, 0069
0131, 0131
0130, 0069
0069, 0069
But, when I use original toupper.c, this proguram output as below.
towupper_l
0049, 0049
0131, 0131
0130, 0069
0069, 0049
towlower_l
0049, 0069
0131, 0131
0130, 0069
0069, 0069
Regards,
Kohji Okuno
>
> On 10 May 2012, at 21:42, Kohji Okuno wrote:
>
>> Hi Eric,
>>
>>> I'm left wondering how this was not caught by the libc++ test
>>> suite. The current toupper.c shouldn't pass
>>> http://llvm.org/svn/llvm-project/libcxx/trunk/test/localization/locales/locale.convenience/conversions/conversions.character/toupper.pass.cpp
>>
>> This test suite checks only popular characters.
>> __mapupper_ext is used in case of special characters.
>>
>> For example, Turkish 'i' (0x0131) should convert 'I' (0x49).
>>
>> Regards,
>> Kohji Okuno
>>
>>
>>> Den 10/05/2012 kl. 12.03 skrev Dimitry Andric:
>>>
On 2012-05-10 11:02, Kohji Okuno wrote:
> I think that libc/locale/toupper.c is mistaken.
> Could you check it?
>
> @@ -51,7 +51,7 @@ ___toupper_l(c, l)
> {
> size_t lim;
> FIX_LOCALE(l);
> - _RuneRange *rr = &XLOCALE_CTYPE(l)->runes->__maplower_ext;
> + _RuneRange *rr = &XLOCALE_CTYPE(l)->runes->__mapupper_ext;
> _RuneEntry *base, *re;
>
> if (c < 0 || c == EOF)
Yes, this definitely looks like a copy/paste error, introduced here:
http://svnweb.freebsd.org/base/head/lib/libc/locale/toupper.c?r1=165903&r2=227753
I'll commit the fix tonight (CEST), if David isn't faster than me. :)
>>>
>>> I'm left wondering how this was not caught by the libc++ test suite. The
>>> current toupper.c shouldn't pass
>>> http://llvm.org/svn/llvm-project/libcxx/trunk/test/localization/locales/locale.convenience/conversions/conversions.character/toupper.pass.cpp
>>>
>>> Thanks,
>>> Erik___
>>> 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: The current libc/locale/toupper.c is mistaken
If you have a test case, I can commit it to the libc++ test suite.
David
On 10 May 2012, at 21:42, Kohji Okuno wrote:
> Hi Eric,
>
>> I'm left wondering how this was not caught by the libc++ test
>> suite. The current toupper.c shouldn't pass
>> http://llvm.org/svn/llvm-project/libcxx/trunk/test/localization/locales/locale.convenience/conversions/conversions.character/toupper.pass.cpp
>
> This test suite checks only popular characters.
> __mapupper_ext is used in case of special characters.
>
> For example, Turkish 'i' (0x0131) should convert 'I' (0x49).
>
> Regards,
> Kohji Okuno
>
>
>> Den 10/05/2012 kl. 12.03 skrev Dimitry Andric:
>>
>>> On 2012-05-10 11:02, Kohji Okuno wrote:
I think that libc/locale/toupper.c is mistaken.
Could you check it?
@@ -51,7 +51,7 @@ ___toupper_l(c, l)
{
size_t lim;
FIX_LOCALE(l);
- _RuneRange *rr = &XLOCALE_CTYPE(l)->runes->__maplower_ext;
+ _RuneRange *rr = &XLOCALE_CTYPE(l)->runes->__mapupper_ext;
_RuneEntry *base, *re;
if (c < 0 || c == EOF)
>>>
>>> Yes, this definitely looks like a copy/paste error, introduced here:
>>>
>>> http://svnweb.freebsd.org/base/head/lib/libc/locale/toupper.c?r1=165903&r2=227753
>>>
>>> I'll commit the fix tonight (CEST), if David isn't faster than me. :)
>>
>> I'm left wondering how this was not caught by the libc++ test suite. The
>> current toupper.c shouldn't pass
>> http://llvm.org/svn/llvm-project/libcxx/trunk/test/localization/locales/locale.convenience/conversions/conversions.character/toupper.pass.cpp
>>
>> Thanks,
>> Erik___
>> 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: The current libc/locale/toupper.c is mistaken
Hi Eric,
> I'm left wondering how this was not caught by the libc++ test
> suite. The current toupper.c shouldn't pass
> http://llvm.org/svn/llvm-project/libcxx/trunk/test/localization/locales/locale.convenience/conversions/conversions.character/toupper.pass.cpp
This test suite checks only popular characters.
__mapupper_ext is used in case of special characters.
For example, Turkish 'i' (0x0131) should convert 'I' (0x49).
Regards,
Kohji Okuno
> Den 10/05/2012 kl. 12.03 skrev Dimitry Andric:
>
>> On 2012-05-10 11:02, Kohji Okuno wrote:
>>> I think that libc/locale/toupper.c is mistaken.
>>> Could you check it?
>>>
>>> @@ -51,7 +51,7 @@ ___toupper_l(c, l)
>>> {
>>>size_t lim;
>>>FIX_LOCALE(l);
>>> - _RuneRange *rr = &XLOCALE_CTYPE(l)->runes->__maplower_ext;
>>> + _RuneRange *rr = &XLOCALE_CTYPE(l)->runes->__mapupper_ext;
>>>_RuneEntry *base, *re;
>>>
>>>if (c < 0 || c == EOF)
>>
>> Yes, this definitely looks like a copy/paste error, introduced here:
>>
>> http://svnweb.freebsd.org/base/head/lib/libc/locale/toupper.c?r1=165903&r2=227753
>>
>> I'll commit the fix tonight (CEST), if David isn't faster than me. :)
>
> I'm left wondering how this was not caught by the libc++ test suite. The
> current toupper.c shouldn't pass
> http://llvm.org/svn/llvm-project/libcxx/trunk/test/localization/locales/locale.convenience/conversions/conversions.character/toupper.pass.cpp
>
> Thanks,
> Erik___
> 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"
usb problems on HP DL980G7
Hi Folks, We've been trying to bring freebsd up on a hp dl980g7 for awhile. Due to usb issues, we finally installed onto a revo card and installed it into the 980. The system consistently puts out the following messages: usbd_ctrl_transfer_setup: could not setup default USB transfer usb_alloc_device: set address 2 failed (USB_ERR_NOMEM, ignored) usbd_ctrl_transfer_setup: could not setup default USB transfer usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_NOMEM usbd_ctrl_transfer_setup: could not setup default USB transfer usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_NOMEM, ignored) usbd_ctrl_transfer_setup: could not setup default USB transfer usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_NOMEM usbd_ctrl_transfer_setup: could not setup default USB transfer usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_NOMEM, ignored) usbd_ctrl_transfer_setup: could not setup default USB transfer usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_NOMEM ugen0.2: at usbus0 (disconnected) uhub_reattach_port: could not allocate new device From dmesg: pci0: at device 20.0 (no driver attached) pcib12: at device 28.0 on pci0 pci3: on pcib12 pcib13: at device 28.4 on pci0 pci2: on pcib13 pci2: at device 0.0 (no driver attached) pci2: at device 0.2 (no driver attached) uhci0: port 0x3c00-0x3c1f irq 17 at device 0.4 on pci2 usbus0 on uhci0 uhci1: port 0x1000-0x101f irq 20 at device 29.0 on pci0 device_attach: uhci1 attach returned 12 uhci1: port 0x1020-0x103f irq 23 at device 29.1 on pci0 device_attach: uhci1 attach returned 12 uhci1: port 0x1040-0x105f irq 22 at device 29.2 on pci0 device_attach: uhci1 attach returned 12 uhci1: port 0x1060-0x107f irq 23 at device 29.3 on pci0 device_attach: uhci1 attach returned 12 ehci0: mem 0xa030-0xa03003ff irq 20 at device 29.7 on pci0 device_attach: ehci0 attach returned 12 Current - 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r235137M Nothing connected to usb on this systems works. Full dmesg is here: http://people.freebsd.org/~jwd/dl980g7/dmesg.boot.html Any help is appreciated. Thanks, John ___ 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: r235163: root: /etc/rc.d/sysctl: WARNING: sysctl vfs.nfs.access_cache_timeout does not exist.
Anton Shterenlikht wrote: > On Thu, May 10, 2012 at 09:51:22PM +0100, Anton Shterenlikht wrote: > > On Thu, May 10, 2012 at 06:11:28PM +0400, Sergey Kandaurov wrote: > > > On 10 May 2012 14:30, Anton Shterenlikht > > > wrote: > > > > > > > > On ia64 r235163: > > > > > > > > root: /etc/rc.d/sysctl: WARNING: sysctl > > > > vfs.nfs.access_cache_timeout does not exist. > > > > > > > > What is this about? > > > > After updating to this revision, > > > > I run mergemaster, as usual, > > > > with the setting to auto update > > > > all /etc files which I didn't touch. > > > > > > I'd check your kernel config for 'options NFSCLIENT', so there is > > > sysctl vfs.oldnfs.access_cache_timeout instead, and you try to set > > > non-existing vfs.nfs.access_cache_timeout from /etc/sysctl.conf. > > > If it is so then all your sysctl vfs.nfs.xxx are named as > > > vfs.oldnfs.xxx, > > > because the NFS implementation enabled with 'options NFSCLIENT' > > > considered old, and the NFS impl. enabled with 'options NFSCL' is > > > the default. > > > My inner voice tells me that you have upgraded from quite old > > > CURRENT > > > from the point when 'options NFSCLIENT' (old nfs) was default to > > > the point > > > when 'options NFSCL' (new nfs implementation) became the default, > > > and you still have 'options NFSCLIENT' in your kernel config. > > > See /usr/src/UPDATING entry dated 20110427. > > > > You are exactly right. > > > > I don't even use NFS anyway. > > So I'll just remove it completely > > from my kernel. > > oh no.. > Seems I do need NFS kernel options for zfs. > If I remove NFS, I get: > > Loading /boot/defaults/loader.conf > /boot/kernel/kernel text=0x966fb0 data=0x96164+0x2161ac > syms=[0x8+0x80718+0x8+0x76ed5] > /boot/kernel/zfs.ko text=0x22e4f8 data=0x9060+0x16de8 > syms=[0x8+0x16c20+0x8+0x11725] > loading required module 'opensolaris' > /boot/kernel/opensolaris.ko text=0x3338 data=0x510+0x2030 > syms=[0x8+0xcd8+0x8+0x872] > loading required module 'krpc' > > KLD zfs.ko: depends on krpc - not available or version mismatch > kldload: can't load zfs: No such file or directory > /etc/rc: WARNING: Unable to load kernel module zfs > > I guess now that zfs needs module acl_nfs4, > the latter needs NFS, right? > > Or can module krpc be loaded instead? > Loading krpc should be ok, since NFS (client and server) requires krpc, but not the other way around (but I haven't actually tried this;-). rick > Anyway, I put new NFS options in the kernel, > and now zfs works ok. > > Thanks > > -- > Anton Shterenlikht > Room 2.6, Queen's Building > Mech Eng Dept > Bristol University > University Walk, Bristol BS8 1TR, UK > Tel: +44 (0)117 331 5944 > Fax: +44 (0)117 929 4423 > ___ > 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: r235163: root: /etc/rc.d/sysctl: WARNING: sysctl vfs.nfs.access_cache_timeout does not exist.
On Thu, May 10, 2012 at 09:51:22PM +0100, Anton Shterenlikht wrote: > On Thu, May 10, 2012 at 06:11:28PM +0400, Sergey Kandaurov wrote: > > On 10 May 2012 14:30, Anton Shterenlikht wrote: > > > > > > On ia64 r235163: > > > > > > root: /etc/rc.d/sysctl: WARNING: sysctl vfs.nfs.access_cache_timeout does > > > not exist. > > > > > > What is this about? > > > After updating to this revision, > > > I run mergemaster, as usual, > > > with the setting to auto update > > > all /etc files which I didn't touch. > > > > I'd check your kernel config for 'options NFSCLIENT', so there is > > sysctl vfs.oldnfs.access_cache_timeout instead, and you try to set > > non-existing vfs.nfs.access_cache_timeout from /etc/sysctl.conf. > > If it is so then all your sysctl vfs.nfs.xxx are named as vfs.oldnfs.xxx, > > because the NFS implementation enabled with 'options NFSCLIENT' > > considered old, and the NFS impl. enabled with 'options NFSCL' is the > > default. > > My inner voice tells me that you have upgraded from quite old CURRENT > > from the point when 'options NFSCLIENT' (old nfs) was default to the point > > when 'options NFSCL' (new nfs implementation) became the default, > > and you still have 'options NFSCLIENT' in your kernel config. > > See /usr/src/UPDATING entry dated 20110427. > > You are exactly right. > > I don't even use NFS anyway. > So I'll just remove it completely > from my kernel. oh no.. Seems I do need NFS kernel options for zfs. If I remove NFS, I get: Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x966fb0 data=0x96164+0x2161ac syms=[0x8+0x80718+0x8+0x76ed5] /boot/kernel/zfs.ko text=0x22e4f8 data=0x9060+0x16de8 syms=[0x8+0x16c20+0x8+0x11725] loading required module 'opensolaris' /boot/kernel/opensolaris.ko text=0x3338 data=0x510+0x2030 syms=[0x8+0xcd8+0x8+0x872] loading required module 'krpc' KLD zfs.ko: depends on krpc - not available or version mismatch kldload: can't load zfs: No such file or directory /etc/rc: WARNING: Unable to load kernel module zfs I guess now that zfs needs module acl_nfs4, the latter needs NFS, right? Or can module krpc be loaded instead? Anyway, I put new NFS options in the kernel, and now zfs works ok. Thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: r235163: root: /etc/rc.d/sysctl: WARNING: sysctl vfs.nfs.access_cache_timeout does not exist.
On Thu, May 10, 2012 at 06:11:28PM +0400, Sergey Kandaurov wrote: > On 10 May 2012 14:30, Anton Shterenlikht wrote: > > > > On ia64 r235163: > > > > root: /etc/rc.d/sysctl: WARNING: sysctl vfs.nfs.access_cache_timeout does > > not exist. > > > > What is this about? > > After updating to this revision, > > I run mergemaster, as usual, > > with the setting to auto update > > all /etc files which I didn't touch. > > I'd check your kernel config for 'options NFSCLIENT', so there is > sysctl vfs.oldnfs.access_cache_timeout instead, and you try to set > non-existing vfs.nfs.access_cache_timeout from /etc/sysctl.conf. > If it is so then all your sysctl vfs.nfs.xxx are named as vfs.oldnfs.xxx, > because the NFS implementation enabled with 'options NFSCLIENT' > considered old, and the NFS impl. enabled with 'options NFSCL' is the default. > My inner voice tells me that you have upgraded from quite old CURRENT > from the point when 'options NFSCLIENT' (old nfs) was default to the point > when 'options NFSCL' (new nfs implementation) became the default, > and you still have 'options NFSCLIENT' in your kernel config. > See /usr/src/UPDATING entry dated 20110427. You are exactly right. I don't even use NFS anyway. So I'll just remove it completely from my kernel. Many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: panic, seems related to r234386
On 05/07/2012 23:14, Sergey Kandaurov wrote: >> > Finally, should my next step be to advance to the latest current + your >> > patch and see how I go from there? > Yep, so that patches will be tested before they go to head. For the record, I upgraded to r235151 + the removal of those 2 locks and haven't had any problems yet. I was going to do one more update today and report back, but you beat me to it. :) Doug -- This .signature sanitized for your protection ___ 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: panic, seems related to r234386
On 8 May 2012 00:11, Mateusz Guzik wrote:
> On Mon, May 07, 2012 at 12:28:41PM -0700, Doug Barton wrote:
>> On 05/06/2012 15:19, Sergey Kandaurov wrote:
>> > On 7 May 2012 01:54, Doug Barton wrote:
>> >> I got this with today's current, previous (working) kernel is r232719.
>> >>
>> >> panic: _mtx_lock_sleep: recursed on non-recursive mutex struct mount mtx
>> >> @ /frontier/svn/head/sys/kern/vfs_subr.c:4595
>>
>> ...
>>
>> > Please try this patch.
>> >
>> > Index: fs/ext2fs/ext2_vfsops.c
>> > ===
>> > --- fs/ext2fs/ext2_vfsops.c (revision 235108)
>> > +++ fs/ext2fs/ext2_vfsops.c (working copy)
>> > @@ -830,7 +830,6 @@
>> > /*
>> > * Write back each (modified) inode.
>> > */
>> > - MNT_ILOCK(mp);
>> > loop:
>> > MNT_VNODE_FOREACH_ALL(vp, mp, mvp) {
>> > if (vp->v_type == VNON) {
>> >
>>
>> Didn't help, sorry. I put 234385 through some pretty heavy load
>> yesterday, and everything was fine. As soon as I move up to 234386, the
>> panic triggered again. So I cleaned everything up, applied your patch,
>> built a kernel from scratch, and rebooted. It was Ok for a few seconds
>> after boot, then panic'ed again, I think in a different place, but I'm
>> not sure because subsequent attempts to fsck the file systems caused new
>> panics which overwrote the old ones before they could be saved.
>>
>
> Another MNT_ILOCK was hiding few lines below, try this patch:
>
> http://student.agh.edu.pl/~mjguzik/patches/ext2fs-ilock.patch
>
> I've tested this a bit and I believe this fixes your problem.
I just committed your fix in r235241 since it seems to have no
relation to the problem reported by Peter Holm.
--
wbr,
pluknet
___
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: r234928 ugen(4) obsolete?
On Thu, May 10, 2012 at 12:30 PM, Anton Shterenlikht wrote: > On amd64 r234928 adding "device ugen" to > the kernel config gives on buildkernel: > > config: Error: device "ugen" is unknown > config: 1 errors > *** [buildkernel] Error code 1 > > ugen(4) man page says nothing about this > driver being obsolete or something similar. > > Is ugen being included as part of some > other driver? I see in dmesg lines like, e.g.: > > ugen0.2: at usbus0 > > even though I haven't built ugen in the kernel. Yes. The USB v2 code made ugen a part of the kernel USB support and and it is no longer a separate driver. I don't know that it's presence in usb(4) is documented anywhere, but it is not in the man page. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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"
r234928 ugen(4) obsolete?
On amd64 r234928 adding "device ugen" to the kernel config gives on buildkernel: config: Error: device "ugen" is unknown config: 1 errors *** [buildkernel] Error code 1 ugen(4) man page says nothing about this driver being obsolete or something similar. Is ugen being included as part of some other driver? I see in dmesg lines like, e.g.: ugen0.2: at usbus0 even though I haven't built ugen in the kernel. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: panic: incorrect npmc count
Le 9 mai 2012 à 16:30, Ryan Stone a écrit : > On Wed, May 9, 2012 at 1:16 AM, Peter Jeremy wrote: >> [This may be a duplicate because I forgot to update my subscription >> after changing address but I've also corrected a typo] >> >> (I've copied fabient@ because r233628 appears to have been the last >> commit in this area). >> >> I've just updated a P4 test box from r232545 to r235127 and it now >> panics during boot: >> panic: [intel,202] incorrect npmc count 35 >> Looking at sys/dev/hwpmc/hmpmc_intel.c line 202, the expected >> npmc count is 19. >> >> When I look at the actual code in pmc_intel_initialize(): >> pmc_mdep_alloc() initialises pmd_npmc to zero and then increments >> it by SOFT_NPMCS (16) in pmc_soft_initialize(). >> pmc_tsc_initialize() then increments it by TSC_NPMCS (1) >> pmc_p4_initialize() then increments it by P4_NPMCS (18) >> This totals 35 (as per the panic message). >> >> Can someone explain the KASSERT() that expects 19 - it boils down to >> KASSERT(0+16+1+18 == 1+18, ...) >> I gather not many people are running -current on a P4. >> >> -- >> Peter Jeremy > > That KASSERT is just out of date. The soft PMC support is quite new. > I would just drop the KASSERT entirely; it really isn't adding any > value. Back from vacation. Yes, as Ryan stated the KASSERT is out of date and i've missed the update / removal with soft PMC. Fixed with r235229. Fabien
Re: r235163: root: /etc/rc.d/sysctl: WARNING: sysctl vfs.nfs.access_cache_timeout does not exist.
On 10 May 2012 14:30, Anton Shterenlikht wrote: > > On ia64 r235163: > > root: /etc/rc.d/sysctl: WARNING: sysctl vfs.nfs.access_cache_timeout does not > exist. > > What is this about? > After updating to this revision, > I run mergemaster, as usual, > with the setting to auto update > all /etc files which I didn't touch. I'd check your kernel config for 'options NFSCLIENT', so there is sysctl vfs.oldnfs.access_cache_timeout instead, and you try to set non-existing vfs.nfs.access_cache_timeout from /etc/sysctl.conf. If it is so then all your sysctl vfs.nfs.xxx are named as vfs.oldnfs.xxx, because the NFS implementation enabled with 'options NFSCLIENT' considered old, and the NFS impl. enabled with 'options NFSCL' is the default. My inner voice tells me that you have upgraded from quite old CURRENT from the point when 'options NFSCLIENT' (old nfs) was default to the point when 'options NFSCL' (new nfs implementation) became the default, and you still have 'options NFSCLIENT' in your kernel config. See /usr/src/UPDATING entry dated 20110427. -- wbr, pluknet ___ 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: SOLVED: Re: KLD zfs.ko: depends on acl_nfs4 - not available or version mismatch
On 10 May 2012 14:23, Anton Shterenlikht wrote: > On Thu, May 10, 2012 at 11:01:21AM +0100, Anton Shterenlikht wrote: >> On ia64 r235163 I get this error >> when trying to load zfs module: >> >> # ls -al /boot/kernel/zfs.ko* >> -r-xr-xr-x 1 root wheel 2496877 May 10 09:15 /boot/kernel/zfs.ko >> -r-xr-xr-x 1 root wheel 6578175 May 10 09:15 /boot/kernel/zfs.ko.symbols >> # kldload zfs >> KLD zfs.ko: depends on acl_nfs4 - not available or version mismatch >> kldload: can't load zfs: No such file or directory > > Figured I now need to add module acl_nfs4: > > makeoptions MODULES_OVERRIDE="geom/geom_part geom/geom_label opensolaris > zfs acl_nfs4" > > The acl_nfs4 module wasn't required before for zfs. > > Where is this change documented? Looks like you stepped on rev 232938 where dependency on acl_nfs4 was added. http://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c?r1=232937&r2=234795 -- wbr, pluknet ___ 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: ports/bash4 --enable-static fails
On 5/10/12 12:20 AM, Craig Rodrigues wrote: > Bash is trying to override the malloc() functions in libc with its own > implementation in lib/malloc/malloc.c . > I have seen this type of trick before 3rd party code that tries to > override the libc implementation of malloc() / free() with its own. > > kan@ explained this to me before, but I don't know if I can explain it > as well as him, because it has to do > with how static linking works. :) > > Basically, the malloc.o object from bash, *must* have implementations of > *all* the relevant functions in jemalloc_jemalloc.o in order for > malloc.o to properly override jemalloc_jemalloc.o. > > If you have something like: > jemalloc_jemalloc.o (libc) malloc.o (Bash) > === = > malloc() malloc() > free() free() > calloc() > realloc() > > > the static linker will not be able to replace jemalloc_jemalloc.o from > libc with malloc.o from Bash, > because calloc() and realloc() symbols in jemalloc_jemalloc.o (libc) > do not exist malloc.o (Bash). > > Since the linker can only deal with whole objects (.o files), it will > try to pull in both > jemalloc_jemalloc.o and malloc.o when doing static linking. > > I may have got some of the details/explanation wrong, but I have fixed > something similar > to this in 3rd party code, when the layout of malloc() functions in > libc changed between FreeBSD 4 and FreeBSD 6. This explanation is substantially correct. > > What you need to do is: >(1) run nm or readelf on jemalloc_jemalloc.o, then run nm or > readelf on malloc.o >(2) Look at the symbols in both >(3) Add the missing symbols to malloc.c in Bash The bash malloc includes definitions for malloc/free/realloc/calloc/cfree/ valloc/memalign. I'd be interested in knowing what other global symbols jemalloc exports. I'd also be interested in seeing how someone managed to compile the bash malloc and leave out realloc. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ ___ 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: The current libc/locale/toupper.c is mistaken
Den 10/05/2012 kl. 12.03 skrev Dimitry Andric:
> On 2012-05-10 11:02, Kohji Okuno wrote:
>> I think that libc/locale/toupper.c is mistaken.
>> Could you check it?
>>
>> @@ -51,7 +51,7 @@ ___toupper_l(c, l)
>> {
>>size_t lim;
>>FIX_LOCALE(l);
>> - _RuneRange *rr = &XLOCALE_CTYPE(l)->runes->__maplower_ext;
>> + _RuneRange *rr = &XLOCALE_CTYPE(l)->runes->__mapupper_ext;
>>_RuneEntry *base, *re;
>>
>>if (c < 0 || c == EOF)
>
> Yes, this definitely looks like a copy/paste error, introduced here:
>
> http://svnweb.freebsd.org/base/head/lib/libc/locale/toupper.c?r1=165903&r2=227753
>
> I'll commit the fix tonight (CEST), if David isn't faster than me. :)
I'm left wondering how this was not caught by the libc++ test suite. The
current toupper.c shouldn't pass
http://llvm.org/svn/llvm-project/libcxx/trunk/test/localization/locales/locale.convenience/conversions/conversions.character/toupper.pass.cpp
Thanks,
Erik___
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: Binary packages for LibreOffice 3.5 or 3.4
On Wed, May 09, 2012 at 01:34:28PM -0700, Doug Barton wrote: > Has anyone answered the original question? Are there going to be > packages for libreoffice? If not, why not? > > Doug Yes as soon as pointyhat builds are uploaded. For example there are libreoffice packages on http://pkgbeta.freebsd.org regards, Bapt pgpGBZbDe3r5W.pgp Description: PGP signature
r235163: root: /etc/rc.d/sysctl: WARNING: sysctl vfs.nfs.access_cache_timeout does not exist.
On ia64 r235163: root: /etc/rc.d/sysctl: WARNING: sysctl vfs.nfs.access_cache_timeout does not exist. What is this about? After updating to this revision, I run mergemaster, as usual, with the setting to auto update all /etc files which I didn't touch. Please advise -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: panic, seems related to r234386
On Thu, May 10, 2012 at 12:21:18PM +0200, Mateusz Guzik wrote:
> On Tue, May 08, 2012 at 09:45:14PM +0200, Peter Holm wrote:
> > On Mon, May 07, 2012 at 10:11:53PM +0200, Mateusz Guzik wrote:
> > > On Mon, May 07, 2012 at 12:28:41PM -0700, Doug Barton wrote:
> > > > On 05/06/2012 15:19, Sergey Kandaurov wrote:
> > > > > On 7 May 2012 01:54, Doug Barton wrote:
> > > > >> I got this with today's current, previous (working) kernel is
> > > > >> r232719.
> > > > >>
> > > > >> panic: _mtx_lock_sleep: recursed on non-recursive mutex struct mount
> > > > >> mtx
> > > > >> @ /frontier/svn/head/sys/kern/vfs_subr.c:4595
> > > >
> > > > ...
> > > >
> > > > > Please try this patch.
> > > > >
> > > > > Index: fs/ext2fs/ext2_vfsops.c
> > > > > ===
> > > > > --- fs/ext2fs/ext2_vfsops.c (revision 235108)
> > > > > +++ fs/ext2fs/ext2_vfsops.c (working copy)
> > > > > @@ -830,7 +830,6 @@
> > > > > /*
> > > > > * Write back each (modified) inode.
> > > > > */
> > > > > - MNT_ILOCK(mp);
> > > > > loop:
> > > > > MNT_VNODE_FOREACH_ALL(vp, mp, mvp) {
> > > > > if (vp->v_type == VNON) {
> > > > >
> > > >
> > > > Didn't help, sorry. I put 234385 through some pretty heavy load
> > > > yesterday, and everything was fine. As soon as I move up to 234386, the
> > > > panic triggered again. So I cleaned everything up, applied your patch,
> > > > built a kernel from scratch, and rebooted. It was Ok for a few seconds
> > > > after boot, then panic'ed again, I think in a different place, but I'm
> > > > not sure because subsequent attempts to fsck the file systems caused new
> > > > panics which overwrote the old ones before they could be saved.
> > > >
> > >
> > > Another MNT_ILOCK was hiding few lines below, try this patch:
> > >
> > > http://student.agh.edu.pl/~mjguzik/patches/ext2fs-ilock.patch
> > >
> > > I've tested this a bit and I believe this fixes your problem.
> > >
> >
> > Gave this a spin and found what looks like a deadlock:
> >
> > http://people.freebsd.org/~pho/stress/log/ext2fs.txt
> >
> > Not a new problem, it would seem. Same issue with 8.3-PRERELEASE r232656M.
> >
>
> pid 2680 (fts) holds lock for vnode cb4be414 and tries to lock cc0ac15c
> pid 2581 (openat) holds lock for vnode cc0ac15c and tries to lock cb4be414
>
> openat calls rmdir foo/bar and ext2_rmdir unlocks and tries to lock
> again foo's vnode.
>
> This is fairly easly reproducible with concurrently running mkdir and fts
> testcase programs that are provided by stress2.
>
> I'll try to come up with a patch by the end of the week.
>
Great. Thank you for looking at this.
- Peter
___
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"
SOLVED: Re: KLD zfs.ko: depends on acl_nfs4 - not available or version mismatch
On Thu, May 10, 2012 at 11:01:21AM +0100, Anton Shterenlikht wrote: > On ia64 r235163 I get this error > when trying to load zfs module: > > # ls -al /boot/kernel/zfs.ko* > -r-xr-xr-x 1 root wheel 2496877 May 10 09:15 /boot/kernel/zfs.ko > -r-xr-xr-x 1 root wheel 6578175 May 10 09:15 /boot/kernel/zfs.ko.symbols > # kldload zfs > KLD zfs.ko: depends on acl_nfs4 - not available or version mismatch > kldload: can't load zfs: No such file or directory Figured I now need to add module acl_nfs4: makeoptions MODULES_OVERRIDE="geom/geom_part geom/geom_label opensolaris zfs acl_nfs4" The acl_nfs4 module wasn't required before for zfs. Where is this change documented? -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: panic, seems related to r234386
On Tue, May 08, 2012 at 09:45:14PM +0200, Peter Holm wrote:
> On Mon, May 07, 2012 at 10:11:53PM +0200, Mateusz Guzik wrote:
> > On Mon, May 07, 2012 at 12:28:41PM -0700, Doug Barton wrote:
> > > On 05/06/2012 15:19, Sergey Kandaurov wrote:
> > > > On 7 May 2012 01:54, Doug Barton wrote:
> > > >> I got this with today's current, previous (working) kernel is r232719.
> > > >>
> > > >> panic: _mtx_lock_sleep: recursed on non-recursive mutex struct mount
> > > >> mtx
> > > >> @ /frontier/svn/head/sys/kern/vfs_subr.c:4595
> > >
> > > ...
> > >
> > > > Please try this patch.
> > > >
> > > > Index: fs/ext2fs/ext2_vfsops.c
> > > > ===
> > > > --- fs/ext2fs/ext2_vfsops.c (revision 235108)
> > > > +++ fs/ext2fs/ext2_vfsops.c (working copy)
> > > > @@ -830,7 +830,6 @@
> > > > /*
> > > > * Write back each (modified) inode.
> > > > */
> > > > - MNT_ILOCK(mp);
> > > > loop:
> > > > MNT_VNODE_FOREACH_ALL(vp, mp, mvp) {
> > > > if (vp->v_type == VNON) {
> > > >
> > >
> > > Didn't help, sorry. I put 234385 through some pretty heavy load
> > > yesterday, and everything was fine. As soon as I move up to 234386, the
> > > panic triggered again. So I cleaned everything up, applied your patch,
> > > built a kernel from scratch, and rebooted. It was Ok for a few seconds
> > > after boot, then panic'ed again, I think in a different place, but I'm
> > > not sure because subsequent attempts to fsck the file systems caused new
> > > panics which overwrote the old ones before they could be saved.
> > >
> >
> > Another MNT_ILOCK was hiding few lines below, try this patch:
> >
> > http://student.agh.edu.pl/~mjguzik/patches/ext2fs-ilock.patch
> >
> > I've tested this a bit and I believe this fixes your problem.
> >
>
> Gave this a spin and found what looks like a deadlock:
>
> http://people.freebsd.org/~pho/stress/log/ext2fs.txt
>
> Not a new problem, it would seem. Same issue with 8.3-PRERELEASE r232656M.
>
pid 2680 (fts) holds lock for vnode cb4be414 and tries to lock cc0ac15c
pid 2581 (openat) holds lock for vnode cc0ac15c and tries to lock cb4be414
openat calls rmdir foo/bar and ext2_rmdir unlocks and tries to lock
again foo's vnode.
This is fairly easly reproducible with concurrently running mkdir and fts
testcase programs that are provided by stress2.
I'll try to come up with a patch by the end of the week.
--
Mateusz Guzik
___
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: The current libc/locale/toupper.c is mistaken
On 2012-05-10 11:02, Kohji Okuno wrote:
> I think that libc/locale/toupper.c is mistaken.
> Could you check it?
>
> @@ -51,7 +51,7 @@ ___toupper_l(c, l)
> {
> size_t lim;
> FIX_LOCALE(l);
> - _RuneRange *rr = &XLOCALE_CTYPE(l)->runes->__maplower_ext;
> + _RuneRange *rr = &XLOCALE_CTYPE(l)->runes->__mapupper_ext;
> _RuneEntry *base, *re;
>
> if (c < 0 || c == EOF)
Yes, this definitely looks like a copy/paste error, introduced here:
http://svnweb.freebsd.org/base/head/lib/libc/locale/toupper.c?r1=165903&r2=227753
I'll commit the fix tonight (CEST), if David isn't faster than me. :)
Thanks!
___
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: The current libc/locale/toupper.c is mistaken
Den 10/05/2012 kl. 11.54 skrev Erik Cederstrand:
> Den 10/05/2012 kl. 11.02 skrev Kohji Okuno:
>
>> Hi,
>>
>> I think that libc/locale/toupper.c is mistaken.
>> Could you check it?
>>
>> @@ -51,7 +51,7 @@ ___toupper_l(c, l)
>> {
>> size_t lim;
>> FIX_LOCALE(l);
>> - _RuneRange *rr = &XLOCALE_CTYPE(l)->runes->__maplower_ext;
>> + _RuneRange *rr = &XLOCALE_CTYPE(l)->runes->__mapupper_ext;
>> _RuneEntry *base, *re;
>
> Which version of toupper.c is this? My
> release/9.0.0/lib/libc/locale/toupper.c already has "__mapupper_ext".
Sorry for the braino, didn't notice this was sent to current@
It was indeed correct until r227753. Cc'ing David Chrisnall.
Thanks,
Erik___
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"
KLD zfs.ko: depends on acl_nfs4 - not available or version mismatch
On ia64 r235163 I get this error when trying to load zfs module: # ls -al /boot/kernel/zfs.ko* -r-xr-xr-x 1 root wheel 2496877 May 10 09:15 /boot/kernel/zfs.ko -r-xr-xr-x 1 root wheel 6578175 May 10 09:15 /boot/kernel/zfs.ko.symbols # kldload zfs KLD zfs.ko: depends on acl_nfs4 - not available or version mismatch kldload: can't load zfs: No such file or directory Please advise -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: The current libc/locale/toupper.c is mistaken
Den 10/05/2012 kl. 11.02 skrev Kohji Okuno:
> Hi,
>
> I think that libc/locale/toupper.c is mistaken.
> Could you check it?
>
> @@ -51,7 +51,7 @@ ___toupper_l(c, l)
> {
>size_t lim;
>FIX_LOCALE(l);
> - _RuneRange *rr = &XLOCALE_CTYPE(l)->runes->__maplower_ext;
> + _RuneRange *rr = &XLOCALE_CTYPE(l)->runes->__mapupper_ext;
>_RuneEntry *base, *re;
Which version of toupper.c is this? My release/9.0.0/lib/libc/locale/toupper.c
already has "__mapupper_ext".
Thanks,
Erik
___
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"
The current libc/locale/toupper.c is mistaken
Hi,
I think that libc/locale/toupper.c is mistaken.
Could you check it?
@@ -51,7 +51,7 @@ ___toupper_l(c, l)
{
size_t lim;
FIX_LOCALE(l);
- _RuneRange *rr = &XLOCALE_CTYPE(l)->runes->__maplower_ext;
+ _RuneRange *rr = &XLOCALE_CTYPE(l)->runes->__mapupper_ext;
_RuneEntry *base, *re;
if (c < 0 || c == EOF)
Best regards,
Kohji Okuno
___
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"
