misc/181090: "zfs list -r" and "zfs list -t all" doesn't show snapshots
>Number: 181090 >Category: misc >Synopsis: "zfs list -r" and "zfs list -t all" doesn't show snapshots >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Aug 06 13:30:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Sandra >Release:9.1 >Organization: >Environment: FreeBSD serv2 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >Description: According to http://docs.oracle.com/cd/E19082-01/817-2271/gaztd/index.html should zfs list -r tank/filesystem show all childs including the snapshots. It doesn't do that. The same problem is with zfs list -t all tank/filesystem which doesn't show the snapshots, which the manpage says it should. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/181092: Invoke the function sendmsg be hung.
>Number: 181092
>Category: misc
>Synopsis: Invoke the function sendmsg be hung.
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Tue Aug 06 14:30:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: jell
>Release:FreeBSD-9.1-RELEASE-i386
>Organization:
jell
>Environment:
FreeBSD jell 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243826: Tue Dec 4 06:55:39
UTC 2012 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386
>Description:
I wrote a simple tools to create a INET6 RAW socket, and try to invoke the
function "sendmsg" to send a message.
And I found when the message size is 9210, the function "sendmsg" will be hung.
>How-To-Repeat:
1. Compile my test code(in attachment)
2. config a ipv6 address like "::6/64"
3. Run my test tools as "./test ::7 9210"
4. The process "test" will be hung.
>Fix:
Patch attached with submission follows:
#include
#include
#include
#include
#include
#include
#include
#include
void set_addr(struct sockaddr *pAddr, int domain, char *pAddress, unsigned
short port)
{
struct sockaddr_in *sin4 = NULL;
struct sockaddr_in6 *sin6 = NULL;
if (domain == AF_INET) {
struct sockaddr_in *sin4 = (struct sockaddr_in *)pAddr;
memset(sin4, 0, sizeof(struct sockaddr_in));
sin4->sin_family = AF_INET;
sin4->sin_port = htons(port);
if (pAddress == NULL) {
sin4->sin_addr.s_addr = htonl(INADDR_ANY);
}
else {
sin4->sin_addr.s_addr = inet_addr(pAddress);
}
}
else {
struct sockaddr_in6 *sin6 = (struct sockaddr_in6 *)pAddr;
memset(sin6, 0, sizeof(struct sockaddr_in6));
sin6->sin6_family = AF_INET6;
sin6->sin6_port = htons(port);
if (pAddress == NULL) {
sin6->sin6_addr = in6addr_any;
}
else {
inet_pton(AF_INET6, pAddress, &sin6->sin6_addr);
}
}
}
void usage()
{
printf("usage:\n\t test ipv6_address send_size\ne.g.\n\ttest 2000:56::56
9183");
exit(0);
}
int main(int argc, char* argv[])
{
int buffer_size = 9183;
int s = -1;
char *pTmpBuffer = NULL;
int nRet = 0;
struct sockaddr_in6 sin6;
char *pAddress;
static struct msghdr smsghdr;
struct iovec iov[2];
static char *scmsg = 0;
struct cmsghdr *scmsgp = 0;
int ip6optlen = 0;
int hoplimit = 200;
if (argc >= 3) {
pAddress = argv[1];/* get the IP address */
buffer_size = atoi(argv[2]); /* get the send buffer size */
if (buffer_size <= 0) {
usage();
}
}
else {
usage();
}
s = socket(AF_INET6, SOCK_RAW, 3);
if (s < 0) {
perror("create socket error\n");
exit(-1);
}
pTmpBuffer = (char *)malloc(buffer_size);
if (pTmpBuffer == NULL) {
perror("malloc failed:");
exit(-1);
}
memset(pTmpBuffer, 0, buffer_size);
memset(&smsghdr, 0, sizeof(smsghdr));
set_addr((struct sockaddr *)&sin6, AF_INET6, pAddress, 0);
smsghdr.msg_name = (char *)&sin6;
smsghdr.msg_namelen = sizeof(sin6);
ip6optlen = CMSG_SPACE(sizeof(int));
scmsg = (char *)malloc(ip6optlen);
smsghdr.msg_control = (caddr_t)scmsg;
smsghdr.msg_controllen = ip6optlen;
scmsgp = (struct cmsghdr *)scmsg;
scmsgp->cmsg_len = CMSG_LEN(sizeof(int));
scmsgp->cmsg_level = IPPROTO_IPV6;
scmsgp->cmsg_type = IPV6_HOPLIMIT;
*(int *)(CMSG_DATA(scmsgp)) = hoplimit;
scmsgp = CMSG_NXTHDR(&smsghdr, scmsgp);
memset(&iov, 0, sizeof(iov));
iov[0].iov_base = (char *)pTmpBuffer;
iov[0].iov_len = buffer_size;
smsghdr.msg_iov = iov;
smsghdr.msg_iovlen = 1;
nRet = sendmsg(s, &smsghdr, 0);
free(pTmpBuffer);
if (nRet < 0) {
perror("sendmsg failed:");
exit(-1);
}
printf("success send size: %d bytes\n", nRet);
return 0;
}
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/127276: commit references a PR
The following reply was made to PR bin/127276; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: bin/127276: commit references a PR
Date: Wed, 7 Aug 2013 00:28:30 + (UTC)
Author: markj
Date: Wed Aug 7 00:28:17 2013
New Revision: 254018
URL: http://svnweb.freebsd.org/changeset/base/254018
Log:
Pass variables prefixed with both LD_ and LD_32_ to the run-time linker.
This prevents unintentional execution of programs when running ldd(1) on
32-bit Linux binaries.
PR: 175339, 127276
Suggested by:kib, rstone
Reviewed by: kib
MFC after: 2 weeks
Modified:
head/usr.bin/ldd/ldd.c
Modified: head/usr.bin/ldd/ldd.c
==
--- head/usr.bin/ldd/ldd.c Wed Aug 7 00:20:30 2013(r254017)
+++ head/usr.bin/ldd/ldd.c Wed Aug 7 00:28:17 2013(r254018)
@@ -49,12 +49,6 @@ __FBSDID("$FreeBSD$");
#include "extern.h"
-#ifdef COMPAT_32BIT
-#define LD_ "LD_32_"
-#else
-#define LD_ "LD_"
-#endif
-
/*
* 32-bit ELF data structures can only be used if the system header[s] declare
* them. There is no official macro for determining whether they are
declared,
@@ -64,6 +58,16 @@ __FBSDID("$FreeBSD$");
#define ELF32_SUPPORTED
#endif
+#define LDD_SETENV(name, value, overwrite) do { \
+ setenv("LD_" name, value, overwrite); \
+ setenv("LD_32_" name, value, overwrite);\
+} while (0)
+
+#define LDD_UNSETENV(name) do { \
+ unsetenv("LD_" name); \
+ unsetenv("LD_32_" name);\
+} while (0)
+
static intis_executable(const char *fname, int fd, int *is_shlib,
int *type);
static void usage(void);
@@ -82,7 +86,7 @@ execldd32(char *file, char *fmt1, char *
char *argv[8];
int i, rval, status;
- unsetenv(LD_ "TRACE_LOADED_OBJECTS");
+ LDD_UNSETENV("TRACE_LOADED_OBJECTS");
rval = 0;
i = 0;
argv[i++] = strdup(_PATH_LDD32);
@@ -121,7 +125,7 @@ execldd32(char *file, char *fmt1, char *
}
while (i--)
free(argv[i]);
- setenv(LD_ "TRACE_LOADED_OBJECTS", "yes", 1);
+ LDD_SETENV("TRACE_LOADED_OBJECTS", "yes", 1);
return (rval);
}
#endif
@@ -210,15 +214,15 @@ main(int argc, char *argv[])
}
/* ld.so magic */
- setenv(LD_ "TRACE_LOADED_OBJECTS", "yes", 1);
+ LDD_SETENV("TRACE_LOADED_OBJECTS", "yes", 1);
if (fmt1 != NULL)
- setenv(LD_ "TRACE_LOADED_OBJECTS_FMT1", fmt1, 1);
+ LDD_SETENV("TRACE_LOADED_OBJECTS_FMT1", fmt1, 1);
if (fmt2 != NULL)
- setenv(LD_ "TRACE_LOADED_OBJECTS_FMT2", fmt2, 1);
+ LDD_SETENV("TRACE_LOADED_OBJECTS_FMT2", fmt2, 1);
- setenv(LD_ "TRACE_LOADED_OBJECTS_PROGNAME", *argv, 1);
+ LDD_SETENV("TRACE_LOADED_OBJECTS_PROGNAME", *argv, 1);
if (aflag)
- setenv(LD_ "TRACE_LOADED_OBJECTS_ALL", "1", 1);
+ LDD_SETENV("TRACE_LOADED_OBJECTS_ALL", "1", 1);
else if (fmt1 == NULL && fmt2 == NULL)
/* Default formats */
printf("%s:\n", *argv);
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/127276: [patch] ldd(1) invokes linux yes
Synopsis: [patch] ldd(1) invokes linux yes State-Changed-From-To: open->patched State-Changed-By: markj State-Changed-When: Wed Aug 7 00:39:53 UTC 2013 State-Changed-Why: This has been fixed with r254018 by passing both LD_TRACE_LOADED_OBJECTS and LD_32_TRACE_LOADED_OBJECTS to the runtime linker. Responsible-Changed-From-To: freebsd-bugs->markj Responsible-Changed-By: markj Responsible-Changed-When: Wed Aug 7 00:39:53 UTC 2013 Responsible-Changed-Why: This has been fixed with r254018 by passing both LD_TRACE_LOADED_OBJECTS and LD_32_TRACE_LOADED_OBJECTS to the runtime linker. http://www.freebsd.org/cgi/query-pr.cgi?pr=127276 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/181078: Loading tun(4) from loader.conf(5) causes panic when kernel already contains device tun(4)
Synopsis: Loading tun(4) from loader.conf(5) causes panic when kernel already contains device tun(4) State-Changed-From-To: open->patched State-Changed-By: markj State-Changed-When: Wed Aug 7 01:37:40 UTC 2013 State-Changed-Why: Fixed in r254020. Thanks! Responsible-Changed-From-To: freebsd-bugs->markj Responsible-Changed-By: markj Responsible-Changed-When: Wed Aug 7 01:37:40 UTC 2013 Responsible-Changed-Why: Fixed in r254020. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=181078 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/181100: Turning up bwi0 crashes / deadlocks the kernel
>Number: 181100 >Category: kern >Synopsis: Turning up bwi0 crashes / deadlocks the kernel >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Aug 07 02:50:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Julio Merino >Release:FreeBSD 10.0-CURRENT powerpc >Organization: >Environment: System: FreeBSD mastodon.meroh.net 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r253975M: Mon Aug 5 20:31:12 EDT 2013 j...@mastodon.meroh.net:/usr/obj/usr/src/sys/GENERIC64 powerpc Kernel does NOT have WITNESS enabled. >Description: I don't know if this is a powerpc-related issue or if it is a generic issue with (possibly) interrupt handling. I'm filing the report in the kern component for triage. I have a PowerMac G5 in which I'm trying to set up a wireless connection. I have installed the bwi-firmware-kmod-3.130.20 package and attempted the following commands: # kldload if_bwi # ifconfig wlan0 create wlandev bwi0 # ifconfig bwi0 up scan as described in the handbook. However, after the third command, the kernel crashes or sometimes apparently deadlocks. The last time this happened resulted in the following messages spewed to the console (manually transcribed): - bwi0: mem 0x80104000-0x80105fff irq 185 at device 1.0 on pci5 bwi0: BBP: id 0x4306, rev 0x2, pkg 0 bwi0: MA bwi0: PHY: type 2, rev 1, ver 1 bwi0: RF: manu 0x17f, type 0x2050, rev 2 bwi0: invalid antenna gain in sprom atapci1 at device 12.1 on pci8 pcib1: failed to reserve resource for pcib8 atapci1: 0x10 bytes of rid 0x20 res 4 failed (0, 0x). atapci1: unable to map interrupt device_attach: atapci1 attach returned 6 wlan0: Ethernet address: xx:xx:xx:xx:xx:xx bwi0: firmware rev 0x0127, patch level 0x000e fatal kernel trap: exception = 0x300 (data storage interrupt) virtual address = 0x6275735f676574 dsisr = 0x4600 srr0 = 0x7c4ed8 srr1 = 0x90009032 lr = 0xcb554590 curthread = 0x25b2b490 pid = 12, comm = irq185: bwi0 [ thread pid 12 tid 100102 ] Stopped at 0x7c4ed8: ld r30, r27, 0x0, - To me, this looks like an interrupt routing problem or some other kind of device conflict. Note that the error messages seem to indicate that. Also, I have no idea why atapci1 appears after bwi0 given that I did not perform any other activities in between the commands mentioned above that could cause a storage device from being attached. This is the output of atapci-related entries in sysctl, which shows nothing about atapci1: - $ sysctl -a | grep atapci mastodon:~> sysctl -a | grep atapci dev.ata.2.%parent: atapci0 dev.ata.3.%parent: atapci0 dev.ata.4.%parent: atapci0 dev.ata.5.%parent: atapci0 dev.atapci.0.%desc: ServerWorks K2 SATA150 controller dev.atapci.0.%driver: atapci dev.atapci.0.%location: slot=12 function=0 dev.atapci.0.%pnpinfo: vendor=0x1166 device=0x0240 subvendor=0x1166 subdevice=0x0240 class=0x01018f name=k2-sata-root compat=k2-s-ata dev.atapci.0.%parent: pci8 - And, finally, atapci messages from dmesg after a reboot, without having loaded bwi0 at all: - mastodon:~> dmesg | grep atapci atapci0: mem 0x8060-0x80601fff irq 128 at device 12.0 on pci8 atapci0: 0x10 bytes of rid 0x20 res 4 failed (0, 0x). ata2: at channel 0 on atapci0 ata3: at channel 1 on atapci0 ata4: at channel 2 on atapci0 ata5: at channel 3 on atapci0 atapci1: at device 12.1 on pci8 atapci1: 0x10 bytes of rid 0x20 res 4 failed (0, 0x). atapci1: unable to map interrupt device_attach: atapci1 attach returned 6 -- I can provide more information if necessary. >How-To-Repeat: On a PowerMac G5 (and possibly other machines): # kldload if_bwi # ifconfig wlan0 create wlandev bwi0 # ifconfig bwi0 up scan >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/181100: [bwi] Turning up bwi0 crashes / deadlocks the kernel
Old Synopsis: Turning up bwi0 crashes / deadlocks the kernel New Synopsis: [bwi] Turning up bwi0 crashes / deadlocks the kernel Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: linimon Responsible-Changed-When: Wed Aug 7 02:52:45 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=181100 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
