Re:offer chemicals
2012-03-16 hf...@dlhuifengyuan.com Dear Purchasing Manager, Have a nice day. Glad to hear that you're in the market for chemical. We specialize in InorganicOrganic chemicals, PigmentDyestuff , Rubber and others,etc. For many years with good quality and competitive price. Our main products as below:titanium dioxide,iron oxide,stpp,ethyl acetate,stearic acid,carbon black and so on. Please free to contact if I could be any further assistant. Free Samples will be sent for your evaluation!Hope to establish business relationship with you! ThanksRegards Ann Dalian HuiFeng Sourse Chemicals Co,.Ltd. Tel: 0086-411-62933075 Fax:0086-0411-62933075 MSN: ann.an...@msn.cn Email: hf...@dlhuifengyuan.com Website: http://www.dlhuifengyuan.com Address:No 11,Taishan Street,ShaKou District,Dalian,China.116021 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
FreeBSD 9.0: Valgrind leaks memory
Hi,
I tried to find a thread about this, but I didn't and in this
threadhttp://forums.freebsd.org/showthread.php?t=16468trasz
suggested to send message to the mailing list.
I've been developing program for Linux under Ubuntu 10.04. I want to get
the code running under my FreeBSD 9.0-RELEASE server. The code compiles
without problems, but Valgrind doesn't work the same way as on my Ubuntu. I
made an example code, which produces a memory leak with Valgrind. The code
is as follows:
### C O D E ###
#include iostream
int main()
{
std::cout Valgrind leaks memory std::endl;
return 0;
}
I compile it simply with command:
g++ test.cc
And then run it in valgrind:
valgrind --show-reachable=yes --tool=memcheck --db-attach=yes
--leak-check=full --track-origins=yes ./a.out
And Valgrind outputs this:
### V AL G R I N D O U T P U T ###
==39783== Memcheck, a memory error detector
==39783== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==39783== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==39783== Command: ./a.out
==39783==
Valgrind leaks memory
==39783==
==39783== HEAP SUMMARY:
==39783== in use at exit: 4,096 bytes in 1 blocks
==39783== total heap usage: 1 allocs, 0 frees, 4,096 bytes allocated
==39783==
==39783== 4,096 bytes in 1 blocks are still reachable in loss record 1 of 1
==39783==at 0x5BF98: malloc (in
/usr/local/lib/valgrind/vgpreload_memcheck-x86-freebsd.so)
==39783==by 0x26B503: ??? (in /lib/libc.so.7)
==39783==by 0x26B3C4: ??? (in /lib/libc.so.7)
==39783==by 0x26AF12: ??? (in /lib/libc.so.7)
==39783==by 0x26AAB4: fwrite (in /lib/libc.so.7)
==39783==by 0xA1135: ??? (in /usr/lib/libstdc++.so.6)
==39783==by 0xDC3C7: std::basic_ostreamchar, std::char_traitschar
std::__ostream_insertchar, std::char_traitschar
(std::basic_ostreamchar, std::char_traitschar , char const*, int) (in
/usr/lib/libstdc++.so.6)
==39783==by 0xDC5DB: std::basic_ostreamchar, std::char_traitschar
std::operator std::char_traitschar (std::basic_ostreamchar,
std::char_traitschar , char const*) (in /usr/lib/libstdc++.so.6)
==39783==by 0x80488C4: main (in /usr/home/ina/test/a.out)
==39783==
==39783== LEAK SUMMARY:
==39783==definitely lost: 0 bytes in 0 blocks
==39783==indirectly lost: 0 bytes in 0 blocks
==39783== possibly lost: 0 bytes in 0 blocks
==39783==still reachable: 4,096 bytes in 1 blocks
==39783== suppressed: 0 bytes in 0 blocks
==39783==
==39783== For counts of detected and suppressed errors, rerun with: -v
==39783== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
In my Ubuntu, Valgrind detects no memory leaks. Although, those reported
leaks are just reachable bytes, but there shouldn't be any of them.
On my Ubuntu g++ and Valgrind versions are as follows:
g++ (Ubuntu 4.4.3-4ubuntu5.1) 4.4.3
valgrind-3.6.0.SVN-Debian
And on FreeBSD:
g++ (GCC) 4.2.1 20070831 patched [FreeBSD]
valgrind-3.6.1
With my actual code, Valgrind reports a lot more memory leaks and also
those mentioned on the thread I linked, but sample code is enough to
produce errors which shouldn't exist.
-Ina
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: bce: Device not configured
On 03/16/12 18:32, YongHyeon PYUN wrote: On Thu, Mar 15, 2012 at 03:20:10PM +0100, Jan Winter wrote: On 03/15/12 18:29, YongHyeon PYUN wrote: On Wed, Mar 14, 2012 at 03:34:20PM +0100, Jan Winter wrote: On 03/14/12 19:40, YongHyeon PYUN wrote: On Tue, Mar 13, 2012 at 02:08:46PM +0100, Jan Winter wrote: Hello, on an Dell Blade m610 is not possible to change the network media option: ifconfig bce0 media 100baseTX mediaopt full-duplex up ifconfig: SIOCSIFMEDIA (media): Device not configured Setting the media option to autoselect and connecting the m610 to a 100 MBit switch, I always get no carrier only 1g full-duplex seems to be working. I have tested this on 8.3-prerelease and 9-stable any Ideas? cheers Jan pciconf -lv bce0@pci0:1:0:0:class=0x02 card=0x02871028 chip=0x163a14e4 rev=0x20 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme II BCM5709S Gigabit Ethernet' class = network subclass = ethernet dmesg bce0:Broadcom NetXtreme II BCM5709 1000Base-SX (C0)mem 0xda00-0xdbff irq 36 at device 0.0 on pci1 miibus0:MII buson bce0 brgphy0:BCM5709S 1000/2500baseSX PHYPHY 2 on miibus0 brgphy0: 1000baseSX-FDX, auto bce0: Ethernet address: 00:26:b9:fb:04:0c bce0: ASIC (0x57092000); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.0.11); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.5) Coal (RX:6,6,18,18; TX:20,20,80,80) bce1:Broadcom NetXtreme II BCM5709 1000Base-SX (C0)mem 0xdc00-0xddff irq 48 at device 0.1 on pci1 miibus1:MII buson bce1 brgphy1:BCM5709S 1000/2500baseSX PHYPHY 2 on miibus1 brgphy1: 1000baseSX-FDX, auto bce1: Ethernet address: 00:26:b9:fb:04:0e bce1: ASIC (0x57092000); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.0.11); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.5) Coal (RX:6,6,18,18; TX:20,20,80,80) I'm not sure you're seeing one of long standing remote PHY issue of blade box but would you try the patch at the following URL? http://people.freebsd.org/~yongari/bce/bce.rphy.diff After applying the patch, show me the dmesg output(bce(4) and brgphy(4) related ones) and 'ifconfig -m bce0'. Note, the patch was not tested at all(lack of hardware). Hello, thank you very much, for your quick support Now its looking much better ifconfig -m bce0 bce0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c01bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE capabilities=c01bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE ether 00:26:b9:fb:04:0c inet 192.168.100.30 netmask 0xff00 broadcast 192.168.100.255 inet6 fe80::226:b9ff:fefb:40c%bce0 prefixlen 64 tentative scopeid 0x1 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseTfull-duplex) status: active supported media: media autoselect media 1000baseT mediaopt full-duplex media 1000baseT media 100baseTX mediaopt full-duplex media 100baseTX media 10baseT/UTP mediaopt full-duplex media 10baseT/UTP dmesg: . bce0:Broadcom NetXtreme II BCM5709 1000Base-SX (C0) mem 0xda00-0xdbff irq 36 at device 0.0 on pci1 bce0: attempting to allocate 1 MSI vectors (16 supported) msi: routing MSI IRQ 256 to local APIC 16 vector 52 bce0: using IRQ 256 for MSI bce0: Remote PHY : TP bce0: bpf attached bce0: Ethernet address: 00:26:b9:fb:04:0c bce0: ASIC (0x57092000); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.0.11); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|Remote PHY(TP)|MFW); MFW (NCSI 2.0.5) Coal (RX:6,6,18,18; TX:20,20,80,80) bce1:Broadcom NetXtreme II BCM5709 1000Base-SX (C0) mem 0xdc00-0xddff irq 48 at device 0.1 on pci1 bce1: attempting to allocate 1 MSI vectors (16 supported) msi: routing MSI IRQ 257 to local APIC 16 vector 53 bce1: using IRQ 257 for MSI bce1: Remote PHY : TP bce1: bpf attached bce1: Ethernet address: 00:26:b9:fb:04:0e bce1: ASIC (0x57092000); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.0.11); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|Remote PHY(TP)|MFW); MFW (NCSI 2.0.5) Coal (RX:6,6,18,18; TX:20,20,80,80) . I have done a quick test with 100 and 1000 MBit, both working very well. Thanks a lot for testing. This patch was made long time ago but I haven't had chance to commit it due to lack of access to hardware. Because the patch bypasses mii(4) layer and makes it hard to read code, I didn't like the patch but it seems the patch makes bce(4) usable on blade boxes at least. I'll commit the patch next week. Its possible to get a Patch for 8 Stable? I will do MFC to stable/[7-9]. And bce.rphy.diff should be applied cleanly to stable/[7-9]. I getting erros with the 8-stable source Oops, try this one for stable/8. http://people.freebsd.org/~yongari/bce/bce.rphy.stable8.diff thank you for
Re: FreeBSD 9.0: Valgrind leaks memory
On 2012-03-16 12:23, Ina J. wrote:
...
I've been developing program for Linux under Ubuntu 10.04. I want to get
the code running under my FreeBSD 9.0-RELEASE server. The code compiles
without problems, but Valgrind doesn't work the same way as on my Ubuntu. I
made an example code, which produces a memory leak with Valgrind. The code
is as follows:
### C O D E ###
#include iostream
int main()
{
std::cout Valgrind leaks memory std::endl;
return 0;
}
This also the case on -CURRENT, and it is because stdio allocates an
output buffer for stdout, and doesn't free it at exit() time. Using C++
is not even necessary, if you use the following C program, the same
occurs:
$ cat test-stdio-leak.c
#include stdio.h
int main(void)
{
puts(Leaky!);
return 0;
}
$ valgrind --show-reachable=yes --tool=memcheck --db-attach=yes
--leak-check=full --track-origins=yes ./test-stdio-leak
==38243== Memcheck, a memory error detector
==38243== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==38243== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==38243== Command: ./test-stdio-leak
==38243==
Leaky!
==38243==
==38243== HEAP SUMMARY:
==38243== in use at exit: 4,096 bytes in 1 blocks
==38243== total heap usage: 1 allocs, 0 frees, 4,096 bytes allocated
==38243==
==38243== 4,096 bytes in 1 blocks are still reachable in loss record 1 of 1
==38243==at 0x6DDE1: malloc (in
/usr/local/lib/valgrind/vgpreload_memcheck-x86-freebsd.so)
==38243==by 0x179E8F: __smakebuf (makebuf.c:72)
==38243==by 0x179D69: __swsetup (wsetup.c:81)
==38243==by 0x1795EB: __sfvwrite (fvwrite.c:66)
==38243==by 0x149D21: puts (puts.c:68)
==38243==by 0x804858C: main (leakc.c:5)
==38243==
==38243== LEAK SUMMARY:
==38243==definitely lost: 0 bytes in 0 blocks
==38243==indirectly lost: 0 bytes in 0 blocks
==38243== possibly lost: 0 bytes in 0 blocks
==38243==still reachable: 4,096 bytes in 1 blocks
==38243== suppressed: 0 bytes in 0 blocks
==38243==
==38243== For counts of detected and suppressed errors, rerun with: -v
==38243== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 1)
If you look in lib/libc/stdio/findfp.c, you will see near the bottom:
/*
* exit() calls _cleanup() through *__cleanup, set whenever we
* open or buffer a file. This chicanery is done so that programs
* that do not use stdio need not link it all in.
*
* The name `_cleanup' is, alas, fairly well known outside stdio.
*/
void
_cleanup()
{
/* (void) _fwalk(fclose); */
(void) _fwalk(__sflush);/* `cheating' */
}
For some reason, since the original BSD 4.4 Lite Lib Sources, the stdio
files are only flushed, not closed, at exit. In practice, it will not
matter much, as the kernel will cleanup any left-overs when the process
dies.
It is probably best to put this leak on valgrind's ignore list.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 9.0: Valgrind leaks memory
On Mar 16, 2012, at 9:52 AM, Dimitry Andric wrote: For some reason, since the original BSD 4.4 Lite Lib Sources, the stdio files are only flushed, not closed, at exit. In practice, it will not matter much, as the kernel will cleanup any left-overs when the process dies. File descriptors get shared between parent and child processes...just because a child process terminates doesn't necessarily mean that you want to close everything. Well, if POSIX 2008's O_CLOEXEC becomes more popular, folks can control whether a descriptor gets inherited an open() time, rather than needing fcntl()'s FD_CLOEXEC and deal with possible race conditions (especially multithreaded programs)... Regards, -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 9.0: Valgrind leaks memory
On Fri, Mar 16, 2012 at 01:23:48PM +0200, Ina J. wrote: Hi, I tried to find a thread about this, but I didn't and in this threadhttp://forums.freebsd.org/showthread.php?t=16468trasz suggested to send message to the mailing list. http://valgrind.org/docs/manual/dist.readme-packagers.html -- Do not ship your Linux distro with a completely stripped /lib/ld.so. At least leave the debugging symbol names on -- line number info isn't necessary. If you don't want to leave symbols on ld.so, alternatively you can have your distro install ld.so's debuginfo package by default, or make ld.so.debuginfo be a requirement of your Valgrind RPM/DEB/whatever. Reason for this is that Valgrind's Memcheck tool needs to intercept calls to, and provide replacements for, some symbols in ld.so at startup (most importantly strlen). If it cannot do that, Memcheck shows a large number of false positives due to the highly optimised strlen (etc) routines in ld.so. This has caused some trouble in the past. As of version 3.3.0, on some targets (ppc32-linux, ppc64-linux), Memcheck will simply stop at startup (and print an error message) if such symbols are not present, because it is infeasible to continue. It's not like this is going to cost you much space. We only need the symbols for ld.so (a few K at most). Not the debug info and not any debuginfo or extra symbols for any other libraries. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
ZFS NFS
I do NFSv3 export of ZFS. root from remote host create files on ZFS witch uid 2^32-2: # ls -l /usr/ports/packages32/ total 6 drwxr-xr-x 2 4294967294 wheel 5 Mar 17 00:57 All drwxr-xr-x 2 4294967294 wheel 5 Mar 17 00:57 Latest drwxr-xr-x 2 4294967294 wheel 3 Mar 17 00:52 archivers drwxr-xr-x 2 4294967294 wheel 4 Mar 17 00:57 lang ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS NFS
Hello, Am 16.03.2012 um 18:20 schrieb Slawa Olhovchenkov: I do NFSv3 export of ZFS. root from remote host create files on ZFS witch uid 2^32-2: # ls -l /usr/ports/packages32/ total 6 drwxr-xr-x 2 4294967294 wheel 5 Mar 17 00:57 All drwxr-xr-x 2 4294967294 wheel 5 Mar 17 00:57 Latest drwxr-xr-x 2 4294967294 wheel 3 Mar 17 00:52 archivers drwxr-xr-x 2 4294967294 wheel 4 Mar 17 00:57 lang Yes? This is expected behaviour of NFS. If you don't want that, try -maproot=root either in sharenfs option to zfs or /etc/exports, whichever it is you are using. HTH, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS NFS
On Fri, Mar 16, 2012 at 06:32:43PM +0100, Patrick M. Hausen wrote: Hello, Am 16.03.2012 um 18:20 schrieb Slawa Olhovchenkov: I do NFSv3 export of ZFS. root from remote host create files on ZFS witch uid 2^32-2: # ls -l /usr/ports/packages32/ total 6 drwxr-xr-x 2 4294967294 wheel 5 Mar 17 00:57 All drwxr-xr-x 2 4294967294 wheel 5 Mar 17 00:57 Latest drwxr-xr-x 2 4294967294 wheel 3 Mar 17 00:52 archivers drwxr-xr-x 2 4294967294 wheel 4 Mar 17 00:57 lang Yes? This is expected behaviour of NFS. If you don't want that, try -maproot=root either in sharenfs option to zfs or /etc/exports, whichever it is you are using. hmm... nobody:*:65534:65534:Unprivileged user:/nonexistent:/usr/sbin/nologin 65534 != 4294967294 (2^16-2 != 2^32-2) Also, I am think ZFS+NFS will be wrong for UID2^15. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS NFS
On Fri, 16 Mar 2012 21:42:33 +0400 Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Fri, Mar 16, 2012 at 06:32:43PM +0100, Patrick M. Hausen wrote: Hello, Am 16.03.2012 um 18:20 schrieb Slawa Olhovchenkov: I do NFSv3 export of ZFS. root from remote host create files on ZFS witch uid 2^32-2: # ls -l /usr/ports/packages32/ total 6 drwxr-xr-x 2 4294967294 wheel 5 Mar 17 00:57 All drwxr-xr-x 2 4294967294 wheel 5 Mar 17 00:57 Latest drwxr-xr-x 2 4294967294 wheel 3 Mar 17 00:52 archivers drwxr-xr-x 2 4294967294 wheel 4 Mar 17 00:57 lang Yes? This is expected behaviour of NFS. If you don't want that, try -maproot=root either in sharenfs option to zfs or /etc/exports, whichever it is you are using. hmm... nobody:*:65534:65534:Unprivileged user:/nonexistent:/usr/sbin/nologin 65534 != 4294967294 (2^16-2 != 2^32-2) And FreeBSD != Linux. Access from root does not get mapped to nobody. See exports(5). Regards Florian signature.asc Description: PGP signature
Re: ZFS NFS
Hello, Am 16.03.2012 um 18:42 schrieb Slawa Olhovchenkov: On Fri, Mar 16, 2012 at 06:32:43PM +0100, Patrick M. Hausen wrote: Hello, Am 16.03.2012 um 18:20 schrieb Slawa Olhovchenkov: I do NFSv3 export of ZFS. root from remote host create files on ZFS witch uid 2^32-2: # ls -l /usr/ports/packages32/ total 6 drwxr-xr-x 2 4294967294 wheel 5 Mar 17 00:57 All drwxr-xr-x 2 4294967294 wheel 5 Mar 17 00:57 Latest drwxr-xr-x 2 4294967294 wheel 3 Mar 17 00:52 archivers drwxr-xr-x 2 4294967294 wheel 4 Mar 17 00:57 lang Yes? This is expected behaviour of NFS. If you don't want that, try -maproot=root either in sharenfs option to zfs or /etc/exports, whichever it is you are using. hmm... nobody:*:65534:65534:Unprivileged user:/nonexistent:/usr/sbin/nologin 65534 != 4294967294 (2^16-2 != 2^32-2) Also, I am think ZFS+NFS will be wrong for UID2^15. I admit I overlooked that one (16 vs 32 bits). But if I'm not mistaken, NFS does not care a bit about the name of the user nobody or the UID in /etc/passwd or what-have-you. It simply sets the UID of remote root (UID 0) to the value -1. And 4294967294 happens to be -1 in 32 bits signed. So - possibly this is built into ZFS this way. I would at least give the sharenfs=... options a try ... HTH, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS NFS
Hi, all, Am 16.03.2012 um 18:51 schrieb Florian Wagner: And FreeBSD != Linux. Access from root does not get mapped to nobody. See exports(5). $ man exports ... In the absence of -maproot and -mapall options, remote accesses by root will result in using a credential of -2:-2. All other users will be mapped to their remote credential. If a -maproot option is given, remote access by root will be mapped to that credential instead of -2:-2. If a -mapall option is given, all users (including root) will be mapped to that credential in place of their own. ... RELENG_8_2 So make that -1 in my last mail a -2. ;-) Kind regards, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS NFS
On Fri, Mar 16, 2012 at 07:34:56PM +0100, Patrick M. Hausen wrote: Hello, Am 16.03.2012 um 18:42 schrieb Slawa Olhovchenkov: On Fri, Mar 16, 2012 at 06:32:43PM +0100, Patrick M. Hausen wrote: Hello, Am 16.03.2012 um 18:20 schrieb Slawa Olhovchenkov: I do NFSv3 export of ZFS. root from remote host create files on ZFS witch uid 2^32-2: # ls -l /usr/ports/packages32/ total 6 drwxr-xr-x 2 4294967294 wheel 5 Mar 17 00:57 All drwxr-xr-x 2 4294967294 wheel 5 Mar 17 00:57 Latest drwxr-xr-x 2 4294967294 wheel 3 Mar 17 00:52 archivers drwxr-xr-x 2 4294967294 wheel 4 Mar 17 00:57 lang Yes? This is expected behaviour of NFS. If you don't want that, try -maproot=root either in sharenfs option to zfs or /etc/exports, whichever it is you are using. hmm... nobody:*:65534:65534:Unprivileged user:/nonexistent:/usr/sbin/nologin 65534 != 4294967294 (2^16-2 != 2^32-2) Also, I am think ZFS+NFS will be wrong for UID2^15. I admit I overlooked that one (16 vs 32 bits). But if I'm not mistaken, NFS does not care a bit about the name of the user nobody or the UID in /etc/passwd or what-have-you. It simply sets the UID of remote root (UID 0) to the value -1. https://blogs.oracle.com/taylor22/entry/nfs_root_access_on_sun === In a default configuration, a Solaris NFS server maps root access to nobody. === http://pubs.opengroup.org/onlinepubs/9629799/chap12.htm#tagcjh_13_03_03 === In some operating systems, a particular user (on UNIX systems, the user ID 0) has access to all files, no matter what permission and ownership they have. This super-user permission might not be allowed on the server, since anyone who can become super-user on their client could gain access to all remote files. A UNIX server by default maps user ID 0 to a distinguished value (UID_NOBODY), as well as mapping the groups list, before doing its access checking. A server implementation may provide a mechanism to change this mapping. This works except for NFS Version 3 protocol root file systems (required for diskless NFS Version 3 protocol client support), where super-user access cannot be avoided. Export options are used, on the server, to restrict the set of clients allowed super-user access. === /usr/include/sys/_types.h:typedef __uint32_t __uid_t; And 4294967294 happens to be -1 in 32 bits signed. So - possibly this is built into ZFS this way. I would at least give the sharenfs=... options a try ... 4294967294 happens to be -2 in 32 bits signed. And I see type of UID (uid_t) is unsigned. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
fxp entering promiscuous mode causing link to bounce
I dont recall seeing this on RELENG_7, but I dont have a box to test with anymore confirm. On one box I upgraded to RELENG_8 I just noticed the nic will bounce if I enable tcpdump on it. Sure enough, trying on a different RELENG_8 box with an fxp nic shows the same result. eg tcpdump -ni fxp0 -c 20 fxp0: link state changed to DOWN fxp0: promiscuous mode enabled fxp0: link state changed to UP fxp0: link state changed to DOWN fxp0: promiscuous mode disabled fxp0: link state changed to UP I verified it on 2 different boxes. Is there a way to prevent this from happening ? fxp0@pci0:0:7:0:class=0x02 card=0x000b8086 chip=0x12298086 rev=0x08 hdr=0x00 vendor = 'Intel Corporation' device = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xfebbb000, size 4096, enabled bar [14] = type I/O Port, range 32, base 0xd800, size 64, enabled bar [18] = type Memory, range 32, base 0xfe90, size 1048576, enabled cap 01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0 and fxp0@pci0:2:1:0:class=0x02 card=0x00408086 chip=0x12298086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xfddff000, size 4096, enabled bar [14] = type I/O Port, range 32, base 0xdf00, size 64, enabled bar [18] = type Memory, range 32, base 0xfddc, size 131072, enabled cap 01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0 fxp0: Intel 82550 Pro/100 Ethernet port 0xdf00-0xdf3f mem 0xfddff000-0xfddf,0xfddc-0xfddd irq 21 at device 1.0 on pci2 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow fxp0: Ethernet address: 00:02:b3:5d:ca:f6 fxp0: [ITHREAD] and fxp0: Intel 82559 Pro/100 Ethernet port 0xd800-0xd83f mem 0xfebbb000-0xfebbbfff,0xfe90-0xfe9f irq 27 at device 7.0 on pci0 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow fxp0: Ethernet address: 00:d0:b7:db:5f:22 fxp0: [ITHREAD] dev.fxp.0.%desc: Intel 82550 Pro/100 Ethernet dev.fxp.0.%driver: fxp dev.fxp.0.%location: slot=1 function=0 dev.fxp.0.%pnpinfo: vendor=0x8086 device=0x1229 subvendor=0x8086 subdevice=0x0040 class=0x02 dev.fxp.0.%parent: pci2 dev.fxp.0.int_delay: 1000 dev.fxp.0.bundle_max: 6 dev.fxp.0.rnr: 61 dev.fxp.0.stats.rx.good_frames: 1085200818 dev.fxp.0.stats.rx.crc_errors: 0 dev.fxp.0.stats.rx.alignment_errors: 0 dev.fxp.0.stats.rx.rnr_errors: 0 dev.fxp.0.stats.rx.overrun_errors: 319 dev.fxp.0.stats.rx.cdt_errors: 0 dev.fxp.0.stats.rx.shortframes: 0 dev.fxp.0.stats.rx.pause: 0 dev.fxp.0.stats.rx.controls: 0 dev.fxp.0.stats.rx.tco: 0 dev.fxp.0.stats.tx.good_frames: 1105041142 dev.fxp.0.stats.tx.maxcols: 0 dev.fxp.0.stats.tx.latecols: 0 dev.fxp.0.stats.tx.underruns: 0 dev.fxp.0.stats.tx.lostcrs: 149 dev.fxp.0.stats.tx.deffered: 0 dev.fxp.0.stats.tx.single_collisions: 0 dev.fxp.0.stats.tx.multiple_collisions: 0 dev.fxp.0.stats.tx.total_collisions: 0 dev.fxp.0.stats.tx.pause: 0 dev.fxp.0.stats.tx.tco: 0 -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: fxp entering promiscuous mode causing link to bounce
If memory serves me right, Mike Tancsa wrote: I dont recall seeing this on RELENG_7, but I dont have a box to test with anymore confirm. On one box I upgraded to RELENG_8 I just noticed the nic will bounce if I enable tcpdump on it. Sure enough, trying on a different RELENG_8 box with an fxp nic shows the same result. JFYI I see this on an ancient i386 system I have, running 9.0-RELEASE: fxp0: Intel 82801BA/CAM (ICH2/3) Pro/100 Ethernet port 0xac00-0xac3f mem 0xefdfe000-0xefdfefff irq 11 at device 8.0 on pci1 Same thing...going into or out of promiscuous mode makes the link bounce. fxp0: link state changed to DOWN fxp0: promiscuous mode enabled fxp0: link state changed to UP fxp0: link state changed to DOWN fxp0: promiscuous mode disabled fxp0: link state changed to UP Bruce. signature.asc Description: OpenPGP digital signature
Re: Changes brought to bce(4) disabling ipmi access during boot
Le 16 mars 2012 à 18:06, YongHyeon PYUN a écrit : On Thu, Mar 15, 2012 at 09:19:27AM +0100, Paul Guyot wrote: Le 15 mars 2012 ? 18:10, YongHyeon PYUN a ?crit : On Wed, Mar 14, 2012 at 11:44:37PM +0100, Paul Guyot wrote: Hello, Changes brought to bce(4) prevents booting a R410 Dell server with GELI-encrypted root ZFS partition requiring a passphrase, something that was possible with 9-RELEASE. Using a binary search, the bug comes from the following revision: Updating collection src-all/cvs Edit src/sys/dev/bce/if_bce.c Add delta 1.89.2.4 2012.01.09.19.07.14 yongari Edit src/sys/dev/bce/if_bcereg.h Add delta 1.35.2.3 2012.01.09.19.07.14 yongari Shutting down connection to server Could you try attach patch and let me know whether it recovers IPMI functionality? Thank you for your quick patch. Unfortunately, it does not recover IPMI functionality with STABLE@2012.01.09.19.08.00. Hmm, how about this one? It did not work either. So I patched the original (RELEASE) driver to print information about the various conditions newly tested by the STABLE driver in bce_miibus_statchg. The result is the following. The box has two bce interfaces, the one connected is bce0. The loader was configured with boot_verbose. Before the passphrase is entered: bce0: Broadcom NetXtreme II BCM5716 1000Base-T (C0) mem 0xda00-0xdbff irq 36 at device 0.0 on pci1 bce0: attempting to allocate 1 MSI vectors (16 supported) bce0: using IRQ 256 for MSI miibus0: MII bus on bce0 bce0: bpf attached bce0: Ethernet address: 78:2b:cb:18:22:75 bce0: [1998] ifp != NULL bce0: [2000] (ifp-if_drv_flags IFF_DRV_RUNNING) == 0 bce0: [2008] mii != NULL bce0: [2023] (mii-mii_media_status IFM_ACTIVE) != IFM_ACTIVE) bce0: [2026] (mii-mii_media_status IFM_AVALID) == IFM_AVALID) bce0: [2058] Unknown link speed, enabling default GMII interface. bce0: [2082] Disabling RX flow control. bce0: [2095] Disabling TX flow control. bce0: ASIC (0x57092008); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.2.3); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.11) bce1: Broadcom NetXtreme II BCM5716 1000Base-T (C0) mem 0xdc00-0xddff irq 48 at device 0.1 on pci1 bce1: attempting to allocate 1 MSI vectors (16 supported) bce1: using IRQ 257 for MSI miibus1: MII bus on bce1 bce1: bpf attached bce1: Ethernet address: 78:2b:cb:18:22:76 bce1: [1998] ifp != NULL bce1: [2000] (ifp-if_drv_flags IFF_DRV_RUNNING) == 0 bce1: [2008] mii != NULL bce1: [2023] (mii-mii_media_status IFM_ACTIVE) != IFM_ACTIVE) bce1: [2026] (mii-mii_media_status IFM_AVALID) == IFM_AVALID) bce1: [2058] Unknown link speed, enabling default GMII interface. bce1: [2082] Disabling RX flow control. bce1: [2095] Disabling TX flow control. bce1: ASIC (0x57092008); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.2.3); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.11) After the passphrase is entered and network is started: bce0: [1998] ifp != NULL bce0: [2000] (ifp-if_drv_flags IFF_DRV_RUNNING) == 0 bce0: [2008] mii != NULL bce0: [2023] (mii-mii_media_status IFM_ACTIVE) != IFM_ACTIVE) bce0: [2026] (mii-mii_media_status IFM_AVALID) == IFM_AVALID) bce0: [2058] Unknown link speed, enabling default GMII interface. bce0: [2082] Disabling RX flow control. bce0: [2095] Disabling TX flow control. bce0: [1998] ifp != NULL bce0: [2002] (ifp-if_drv_flags IFF_DRV_RUNNING) != 0 bce0: [2008] mii != NULL bce0: [2018] (mii-mii_media_status (IFM_ACTIVE | IFM_AVALID)) == (IFM_ACTIVE | IFM_AVALID) bce0: [2053] Enabling GMII interface. bce0: [2082] Disabling RX flow control. bce0: [2095] Disabling TX flow control. bce0: link state changed to UP bce0: Gigabit link up! bce0: Gigabit link up! bce0: Gigabit link up! From what I understand, both new conditions that may return early are true ((ifp-if_drv_flags IFF_DRV_RUNNING) == 0 and later (mii-mii_media_status IFM_ACTIVE) != IFM_ACTIVE), which yields bce_link_up to be FALSE. Yet I am confused by the role of actually writing to BCE_EMAC_MODE in order to keep the iDRAC link up, and wether the issue would not come from another part of the change. Paul
Re: fxp entering promiscuous mode causing link to bounce
On Fri, 16 Mar 2012 16:49:54 -0400, Mike Tancsa wrote: I dont recall seeing this on RELENG_7, but I dont have a box to test with anymore confirm. On one box I upgraded to RELENG_8 I just noticed the nic will bounce if I enable tcpdump on it. Sure enough, trying on a different RELENG_8 box with an fxp nic shows the same result. eg tcpdump -ni fxp0 -c 20 fxp0: link state changed to DOWN fxp0: promiscuous mode enabled fxp0: link state changed to UP fxp0: link state changed to DOWN fxp0: promiscuous mode disabled fxp0: link state changed to UP I verified it on 2 different boxes. Is there a way to prevent this from happening ? Confirmed on 8.2-RELEASE. I hadn't noticed as I tend to use tcpdump -p Mar 17 14:00:03 t23 kernel: fxp0: link state changed to DOWN Mar 17 14:00:03 t23 kernel: fxp0: promiscuous mode enabled Mar 17 14:00:05 t23 kernel: fxp0: link state changed to UP Mar 17 14:00:14 t23 kernel: fxp0: link state changed to DOWN Mar 17 14:00:14 t23 kernel: fxp0: promiscuous mode disabled Mar 17 14:00:16 t23 kernel: fxp0: link state changed to UP I've also noticed that it consistently takes a couple of seconds after enabling or disabling promisc mode before coming back UP here. There were several updates to fxp between 7 and 8.0 through 8.1-STABLE upto 8.2-R, concerning UP/DOWN occurrence and timing at boot, around suspend/resume and dhclient. I'd been watching it with some suspicion regarding a suspend/resume issue (that turned out to be usb-related). cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
