Re: misc/176656: Headphones redirection for Lenovo T420 and T520
Synopsis: Headphones redirection for Lenovo T420 and T520 Responsible-Changed-From-To: freebsd-bugs->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Wed Mar 6 13:38:35 UTC 2013 Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=176656 ___ 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/176636: Periodical crashes with 9.1-R
The following reply was made to PR kern/176636; it has been noted by GNATS. From: Andriy Gapon To: Rasmus Skaarup Cc: bug-follo...@freebsd.org Subject: Re: kern/176636: Periodical crashes with 9.1-R Date: Wed, 06 Mar 2013 15:36:38 +0200 Is this on the same physical machine where you got the vm_page_free_toq panic or on a different machine? Please test the change on a machine different from the machine where you were getting all the different panics that you described in the other/previous PR. -- Andriy Gapon ___ 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/176636: Periodical crashes with 9.1-R
The following reply was made to PR kern/176636; it has been noted by GNATS. From: Rasmus Skaarup To: Andriy Gapon Cc: bug-follo...@freebsd.org Subject: Re: kern/176636: Periodical crashes with 9.1-R Date: Wed, 6 Mar 2013 15:24:27 +0100 Yes, I have tried to move the virtual machine to two different other = physical hosts. Exactly the same crashes there. Is it a failure in the ZFS filesystem that causes the panics? Best regards, Rasmus Skaarup= ___ 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/176636: Periodical crashes with 9.1-R
The following reply was made to PR kern/176636; it has been noted by GNATS. From: Andriy Gapon To: Rasmus Skaarup Cc: bug-follo...@freebsd.org Subject: Re: kern/176636: Periodical crashes with 9.1-R Date: Wed, 06 Mar 2013 16:40:49 +0200 on 06/03/2013 16:24 Rasmus Skaarup said the following: > > Yes, I have tried to move the virtual machine to two different other > physical hosts. Exactly the same crashes there. > > Is it a failure in the ZFS filesystem that causes the panics? Since the panics look so random I can not really say. -- Andriy Gapon ___ 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/176636: Periodical crashes with 9.1-R
The following reply was made to PR kern/176636; it has been noted by GNATS. From: Rasmus Skaarup To: Andriy Gapon Cc: bug-follo...@freebsd.org Subject: Re: kern/176636: Periodical crashes with 9.1-R Date: Wed, 6 Mar 2013 15:55:50 +0100 The panics are all zfs related. I occurs like clock work when I type = "zpool status". Br Rasmus Skaarup On 06/03/2013, at 15.40, Andriy Gapon wrote: > on 06/03/2013 16:24 Rasmus Skaarup said the following: >>=20 >> Yes, I have tried to move the virtual machine to two different other = physical hosts. Exactly the same crashes there. >>=20 >> Is it a failure in the ZFS filesystem that causes the panics? >=20 > Since the panics look so random I can not really say. >=20 > --=20 > Andriy Gapon >=20 ___ 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/176636: Periodical crashes with 9.1-R
The following reply was made to PR kern/176636; it has been noted by GNATS. From: Andriy Gapon To: Rasmus Skaarup Cc: bug-follo...@freebsd.org Subject: Re: kern/176636: Periodical crashes with 9.1-R Date: Wed, 06 Mar 2013 16:59:49 +0200 on 06/03/2013 16:55 Rasmus Skaarup said the following: > > The panics are all zfs related. I occurs like clock work when I type "zpool > status". They do happen in random places all over the zfs code. -- Andriy Gapon ___ 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/176636: Periodical crashes with 9.1-R
The following reply was made to PR kern/176636; it has been noted by GNATS. From: Rasmus Skaarup To: Andriy Gapon Cc: bug-follo...@freebsd.org Subject: Re: kern/176636: Periodical crashes with 9.1-R Date: Wed, 6 Mar 2013 16:22:59 +0100 Tonight I will migrate all data to a UFS drive and let it run for a few = days. If it works, I will create a new ZFS pool and move data back and = see what happens. Is there any information you need before I proceed? Br Rasmus Skaarup= ___ 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/176694: KVM Guest Crash at Boot - kernel trap 12 with interrupts disabled
>Number: 176694 >Category: misc >Synopsis: KVM Guest Crash at Boot - kernel trap 12 with interrupts >disabled >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: Wed Mar 06 15:50:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Juergen Gotteswinter >Release:9.0 / 9.1 >Organization: InterNetX GmbH >Environment: not possible, system never booted >Description: Trying to Install a 9.0 or 9.1 FreeBSD Guest on a Linux KVM Host ends in the following error message directly after the Boot Menu: kernel trap 12 with interrupts disabled Enabling Verbose does not show more Information. Tried to set hw.mca.enabled=0 and disabled acpi, without effect. Tested FreeBSD 8.3, which works when setting hw.mca.enabled=0. It seems like this Bug is initially triggered by the Qemu -cpu Parameter, when "-cpu Opteron_G4" is set, this Bug happens. >How-To-Repeat: Try to Install a FreeBSD 9.x Guest on a Linux KVM Host with qemu Parameter "-cpu Opteron_G4" /usr/libexec/qemu-kvm -S -M rhel6.3.0 -cpu Opteron_G4 -enable-kvm -m 4096 -smp 8,sockets=2,cores=4,threads= >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: misc/176694: KVM Guest Crash at Boot - kernel trap 12 with interrupts disabled
The following reply was made to PR misc/176694; it has been noted by GNATS. From: InterNetX - Juergen Gotteswinter To: bug-follo...@freebsd.org Cc: Subject: Re: misc/176694: KVM Guest Crash at Boot - kernel trap 12 with interrupts disabled Date: Wed, 06 Mar 2013 17:09:00 +0100 -HEAD shows the same Problem. So far only 8.x seems to be fine. -- InterNetX GmbH Maximilianstr. 6 93047 Regensburg Germany Tel. +49 941 59559-480 Fax +49 941 59559-245 www.internetx.com www.facebook.com/InterNetX www.twitter.com/InterNetX Geschaftsführer/CEO: Thomas Mörz Amtsgericht Regensburg, HRB 7142 ___ 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"
bin/176697: incorrect fetch(1) exit codes with -s option versus ftp proxy use
>Number: 176697 >Category: bin >Synopsis: incorrect fetch(1) exit codes with -s option versus ftp proxy >use >Confidential: no >Severity: serious >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Mar 06 19:20:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Matthias Andree >Release:FreeBSD 9.1-RELEASE amd64 >Organization: >Environment: System: FreeBSD apollo.emma.line.org 9.1-RELEASE FreeBSD 9.1-RELEASE #2 r244869: Sun Dec 30 22:05:16 CET 2012 t...@apollo.emma.line.org:/usr/obj/usr/src/sys/GENERIC amd64 >Description: fetch -s exit codes are not consistent across proxy vs. non-proxy setups when checking for a non-existent file on an ftp server, with fetch -svv ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/8.3-RELEASE/base.txz With Squid as proxy, we get exit code 1 (correct) and an error message. Without proxy, we get "Unknown" as result, and an exit code of 0 (bogus). Since fetch failed to obtain the requested file size, it must not use EXIT_SUCCESS (0), but must report the error. Expected behaviour: fetch should, when it is unable to obtain the file size, always exit with code 1 after printing an error message. Log, first the correct case with proxy: $ fetch -svv ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/8.3-RELEASE/base.txz ; echo $? scheme: [ftp] user: [] password: [] host: [ftp.freebsd.org] port: [0] document: [/pub/FreeBSD/releases/amd64/8.3-RELEASE/base.txz] scheme: [http] user: [] password: [] host: [proxy] port: [8080] document: [/] ---> proxy:8080 looking up proxy connecting to proxy:8080 requesting ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/8.3-RELEASE/base.txz >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: >>> HEAD ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/8.3-RELEASE/base.txz >>> HTTP/1.1 >>> Host: ftp.freebsd.org >>> User-Agent: fetch libfetch/2.0 >>> Connection: close >>> <<< HTTP/1.1 404 Not Found <<< Server: squid/3.2.7 <<< Mime-Version: 1.0 <<< Date: Wed, 06 Mar 2013 18:33:46 GMT <<< Content-Type: text/html <<< Content-Length: 3807 <<< X-Squid-Error: ERR_FTP_NOT_FOUND 0 content length: [3807] <<< Vary: Accept-Language <<< Content-Language: en <<< X-Cache: MISS from proxy.madpilot.net <<< Via: 1.1 proxy.madpilot.net (squid/3.2.7) <<< Connection: close <<< offset 0, length -1, size -1, clength 3807 fetch: Not Found 1 Now the faulty one, without proxy: $ /usr/bin/fetch -svvv ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/8.3-RELEASE/base.txz ; echo $? scheme: [ftp] user: [] password: [] host: [ftp.freebsd.org] port: [0] document: [/pub/FreeBSD/releases/amd64/8.3-RELEASE/base.txz] ---> ftp.freebsd.org:21 looking up ftp.freebsd.org connecting to ftp.freebsd.org:21 <<< 220 beastie.tdk.net FTP server (Version 6.00LS) ready. >>> USER anonymous <<< 331 Guest login ok, send your email address as password. >>> PASS mand...@apollo.emma.line.org <<< 230 Guest login ok, access restrictions apply. >>> PWD <<< 257 "/" is current directory. >>> CWD pub/FreeBSD/releases/amd64/8.3-RELEASE <<< 250 CWD command successful. >>> MODE S <<< 200 MODE S accepted. >>> TYPE I <<< 200 Type set to I. >>> SIZE base.txz <<< 550 base.txz: No such file or directory. >>> QUIT <<< 221 Goodbye. Unknown 0 ___ 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/176700: Update Ports to prevent build with PKGNG and update Maintainer's E-Mail
>Number: 176700
>Category: misc
>Synopsis: Update Ports to prevent build with PKGNG and update
>Maintainer's E-Mail
>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: Wed Mar 06 20:20:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: Hannes
>Release:9.1-RELEASE
>Organization:
FSFE
>Environment:
FreeBSD fbsdmain 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:
see Synopsis
>How-To-Repeat:
>Fix:
PATCH 1
-- kportsORIG/Makefile 2012-11-17 07:00:45.0 +0100
+++ kports/Makefile 2013-03-06 21:04:56.177551451 +0100
@@ -11,7 +11,7 @@
CATEGORIES=ports-mgmt kde
MASTER_SITES= SF
-MAINTAINER=kpo...@soulrebel.in-berlin.de
+MAINTAINER=h2+fbsdpo...@fsfe.org
COMMENT= KDE3-Version of your favorite frontend to the Ports
USE_BZIP2= yes
@@ -30,6 +30,10 @@
.include
+.if defined(WITH_PKGNG)
+IGNORE=Only works with traditional pkg-tools
+.endif
+
.if defined(WITHOUT_KDESU) && defined(WITHOUT_KDESU4) && defined(WITHOUT_GKSU)
PKGMESSAGE=${FILESDIR}/pkg-message.nosu
.endif
PATCH2
diff -ru kports-qt4ORIG/Makefile kports-qt4/Makefile
--- kports-qt4ORIG/Makefile 2012-11-17 07:00:45.0 +0100
+++ kports-qt4/Makefile 2013-03-06 21:05:53.055673670 +0100
@@ -11,7 +11,7 @@
CATEGORIES=ports-mgmt kde
MASTER_SITES= SF
-MAINTAINER=kpo...@soulrebel.in-berlin.de
+MAINTAINER=h2+fbsdpo...@fsfe.org
COMMENT= Qt4-Version of your favorite frontend to the Ports
RUN_DEPENDS= portaudit:${PORTSDIR}/ports-mgmt/portaudit \
@@ -33,6 +33,10 @@
OXYGEN "Pull in Oxygen icons (recommended)" on \
KDEBASE "Pull in kdebase-runtime for kdesu" on
+.if defined(WITH_PKGNG)
+IGNORE=Only works with traditional pkg-tools
+.endif
+
.include
.if !defined(WITHOUT_OXYGEN)
>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: misc/176628: [stdint.h] use safer way of definint __WORDSIZE
* Bruce Evans (b...@optusnet.com.au) wrote: > > __WORDSIZE is always defined as 32, which is wrong on 64bit systems. > > > > I have two solutions for the problem. > > First one uses the same way of testing for 64bit pointers, but doesn't > > define __WORDSIZE if it can't be detected reliably. > > C++ code should be happier with __WORDSIZE being undefined that with it > being defined to garbage. > > > Second one uses different way of testing for 64bit pointers with checking > > for __LP64__. > > > > The second one looks much more useful, but I'm not sure if __LP64__ has the > > right semantics and will work in all platforms. > > Not right, but better than the UINTPTR_MAX test. Both are broken and default > to __WORDSIZE == 32 if pointers are not precisely 64 bits. Actually, the > __LP64__ test is more fragile, since it fails if __L32_P64__ and many systems > use that. Just not any FreeBSD systems, so it is valid to use a hackish > ifdef that only works on current FreeBSD systems. So, what solution do you think is the best in current situation? -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ 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: misc/176628: [stdint.h] use safer way of definint __WORDSIZE
The following reply was made to PR kern/176628; it has been noted by GNATS. From: Dmitry Marakasov To: Bruce Evans Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Subject: Re: misc/176628: [stdint.h] use safer way of definint __WORDSIZE Date: Thu, 7 Mar 2013 00:38:44 +0400 * Bruce Evans (b...@optusnet.com.au) wrote: > > __WORDSIZE is always defined as 32, which is wrong on 64bit systems. > > > > I have two solutions for the problem. > > First one uses the same way of testing for 64bit pointers, but doesn't > > define __WORDSIZE if it can't be detected reliably. > > C++ code should be happier with __WORDSIZE being undefined that with it > being defined to garbage. > > > Second one uses different way of testing for 64bit pointers with checking > > for __LP64__. > > > > The second one looks much more useful, but I'm not sure if __LP64__ has > > the right semantics and will work in all platforms. > > Not right, but better than the UINTPTR_MAX test. Both are broken and default > to __WORDSIZE == 32 if pointers are not precisely 64 bits. Actually, the > __LP64__ test is more fragile, since it fails if __L32_P64__ and many systems > use that. Just not any FreeBSD systems, so it is valid to use a hackish > ifdef that only works on current FreeBSD systems. So, what solution do you think is the best in current situation? -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ 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: ports/176700: Update ports-mgmt/kports and kports-qt4 to prevent build with PKGNG and update Maintainer's E-Mail
Old Synopsis: Update Ports to prevent build with PKGNG and update Maintainer's E-Mail New Synopsis: Update ports-mgmt/kports and kports-qt4 to prevent build with PKGNG and update Maintainer's E-Mail Responsible-Changed-From-To: freebsd-bugs->freebsd-ports-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 6 22:46:14 UTC 2013 Responsible-Changed-Why: ports PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=176700 ___ 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: junk/176682: hi
Synopsis: hi State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Wed Mar 6 22:53:36 UTC 2013 State-Changed-Why: spam http://www.freebsd.org/cgi/query-pr.cgi?pr=176682 ___ 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"
bin/176713: nc(1) closes network socket too soon
>Number: 176713
>Category: bin
>Synopsis: nc(1) closes network socket too soon
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Thu Mar 07 02:50:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: Ronald F. Guilmette
>Release:FreeBSD 9.1-RELEASE amd64
>Organization:
entr0py
>Environment:
System: FreeBSD 9.1-RELEASE FreeBSD amd64
>Description:
As described in this thread:
https://bugs.launchpad.net/ubuntu/+source/netcat-openbsd/+bug/544935
numerous people have, like me, encountered a serious problem with nc(1),
specifically that it prematurely closes the connection to the remote network
server being accessed as soon as it senses EOF on its stdin channel.
As can been see by perusing the above web page, this problem can cause,
and has caused much gnashing of teeth and tearing of hair in many quarters.
It is certainly possible that some existing scripts and/or applications
may perhaps depend on the current/existing behavior, and thus, it may
perhaps not be considered wise to change the existing behavior at this
(late?) point in time. However there are quite certainly many situations
in which the different behavior (of gathering and outputting all output
from the remote server before closing down) can be unambiguously useful,
if not to say utterly irreplacable. For these reasons I propse the addition
of a new "-q" option (no arguments) for nc(1) which, when used would change
the program's behavior, causing it to wait for EOF from the remote network
server before closing down and exiting.
I provide implementation patches for exactly such a change below.
>How-To-Repeat:
echo 193.0.6.139 | nc whois.ripe.net 43
((note how the output produced by the above command pipeline gets chopped
off prematurely))
Fix:
Simple/trivial context diff patches (implementing -q) attached below.
*** netcat.c2012-12-03 10:55:02.0 -0800
--- netcat.c2013-03-06 18:10:10.0 -0800
***
*** 82,87
--- 82,88
int FreeBSD_Oflag; /* Do not use TCP options */
char *Pflag;/* Proxy username */
char *pflag;/* Localport flag */
+ int qflag; /* quit on remote EOF flag */
int rflag; /* Random ports flag */
char *sflag;/* Source Address */
int tflag; /* Telnet Emulation */
***
*** 153,159
sv = NULL;
while ((ch = getopt_long(argc, argv,
! "46DdEe:hI:i:jklnoO:P:p:rSs:tT:UuV:vw:X:x:z",
longopts, NULL)) != -1) {
switch (ch) {
case '4':
--- 154,160
sv = NULL;
while ((ch = getopt_long(argc, argv,
! "46DdEe:hI:i:jklnoO:P:p:qrSs:tT:UuV:vw:X:x:z",
longopts, NULL)) != -1) {
switch (ch) {
case '4':
***
*** 224,229
--- 225,233
case 'p':
pflag = optarg;
break;
+ case 'q':
+ qflag = 1;
+ break;
case 'r':
rflag = 1;
break;
***
*** 823,829
if ((n = read(wfd, buf, plen)) < 0)
return;
else if (n == 0) {
! shutdown(nfd, SHUT_WR);
pfd[1].fd = -1;
pfd[1].events = 0;
} else {
--- 827,834
if ((n = read(wfd, buf, plen)) < 0)
return;
else if (n == 0) {
! if (!qflag)
! shutdown(nfd, SHUT_WR);
pfd[1].fd = -1;
pfd[1].events = 0;
} else {
>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/176636: Periodical crashes with 9.1-R
The following reply was made to PR kern/176636; it has been noted by GNATS. From: Rasmus Skaarup To: Andriy Gapon Cc: bug-follo...@freebsd.org Subject: Re: kern/176636: Periodical crashes with 9.1-R Date: Thu, 7 Mar 2013 06:00:46 +0100 This is the only kind of panic I get - after your patch: Fatal trap 12: page fault while in kernel mode cpuid =3D 1; apic id =3D 01 fault virtual address =3D 0x60 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0x8162e4f0 stack pointer =3D 0x28:0xff81624726e0 frame pointer =3D 0x28:0xff81624727d0 code segment=3D base 0x0, limit 0xf, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags=3D interrupt enabled, resume, IOPL =3D 0 current process =3D 26068 (zpool) trap number =3D 12 panic: page fault cpuid =3D 1 KDB: stack backtrace: #0 0x809208a6 at kdb_backtrace+0x66 #1 0x808ea8be at panic+0x1ce #2 0x80bd8240 at trap_fatal+0x290 #3 0x80bd857d at trap_pfault+0x1ed #4 0x80bd8b9e at trap+0x3ce #5 0x80bc315f at calltrap+0x8 #6 0x81673975 at sa_handle_get_from_db+0x95 #7 0x81673a38 at sa_handle_get+0x48 #8 0x8169f516 at zfs_grab_sa_handle+0x96 #9 0x8169faca at zfs_obj_to_path+0x6a #10 0x816b8c75 at zfs_ioc_obj_to_path+0x75 #11 0x816bad46 at zfsdev_ioctl+0xe6 #12 0x807db28b at devfs_ioctl_f+0x7b #13 0x80932325 at kern_ioctl+0x115 #14 0x8093255d at sys_ioctl+0xfd #15 0x80bd7ae6 at amd64_syscall+0x546 #16 0x80bc3447 at Xfast_syscall+0xf7 Br Rasmus On 06/03/2013, at 16.22, Rasmus Skaarup wrote: >=20 > Tonight I will migrate all data to a UFS drive and let it run for a = few days. If it works, I will create a new ZFS pool and move data back = and see what happens. >=20 > Is there any information you need before I proceed? >=20 > Br > Rasmus Skaarup ___ 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/176722: OpenSSL 1.0.1e fails to fallback to TLS1 if the server doesn't allow for anything else
>Number: 176722 >Category: misc >Synopsis: OpenSSL 1.0.1e fails to fallback to TLS1 if the server doesn't >allow for anything else >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: Thu Mar 07 07:40:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Johannes Meixner >Release:10.0-CURRENT >Organization: >Environment: FreeBSD xmj.local 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r247490M: Fri Mar 1 19:16:27 EET 2013 root@xmj.local:/usr/obj/usr/src/sys/xmj amd64 >Description: Error first described by Pablo Almeida on https://bugs.launchpad.net/openssl/+bug/965371/ -- when trying to `openssl s_client -showcerts -connect coremis-cas.myocean.eu:443' OpenSSL1.0.1e (11 Feb 13 from ports) doesn't fall back (as it does for 0.9.8x 10 May 2012) to TLS1 and, instead of showing certs, gives CONNECTED(0004) --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 319 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- However, when forcing s_client to use -tls1, the result is as expected, returning the site's certificates. Why doesn't openssl notice it can't any other method but TLS1 -- and fall back to that one, as in previous versions? >How-To-Repeat: Run `openssl s_client -showcerts -connect coremis-cas.myocean.eu:443' on OpenSSL 1.0.1e versus openssl s_client -showcerts -tls1 -connect coremis-cas.myocean.eu:443 >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"
