misc/188714: [patch] A bug in fortune message db
>Number: 188714 >Category: misc >Synopsis: [patch] A bug in fortune message db >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Thu Apr 17 08:00:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Makoto Kishimoto >Release:10.0-RELEASE-p1 >Organization: N/A >Environment: FreeBSD norikura.localdomain 10.0-RELEASE-p1 FreeBSD 10.0-RELEASE-p1 #0: Tue Apr 8 06:45:06 UTC 2014 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 >Description: There is a bug in fortune message db, see patch >How-To-Repeat: fortune -m 'The integral of z squared' >Fix: see patch Patch attached with submission follows: Index: games/fortune/datfiles/fortunes === --- games/fortune/datfiles/fortunes (revision 264582) +++ games/fortune/datfiles/fortunes (working copy) @@ -570,7 +570,7 @@ the verb. Last but not least, avoid cliches like the plague; seek viable alternatives. % - 1/2 + 1/3 /\(3) | 2 1/3 |z dz cos(3 * PI / 9) = ln (e ) @@ -578,7 +578,7 @@ \/ 1 The integral of z squared, dz -From 1 to the square root of 3 +From 1 to the cube root of 3 Times the cosine Of 3 PI over nine Is the log of the cube root of e >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"
bin/188715: int64 not handled right as arg on badsect(8), possible other issues lurking
>Number: 188715 >Category: bin >Synopsis: int64 not handled right as arg on badsect(8), possible other >issues lurking >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 Apr 17 08:20:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Dirk-Willem van Gulik >Release:9.2-RELEASE-p3 >Organization: Web Weaving >Environment: pikmeer.webweaving.org 9.2-RELEASE-p3 FreeBSD 9.2-RELEASE-p3 #0: Sat Jan 11 02:38:15 UTC 2014 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 >Description: Was trying to map out some bad blocks prior to temporarily read/empty 4 Tbyte volume using badsect(8) - and returing it. Was expecting to be able to put the sector # into badsect (e.g. 3432631424 from below FSCK output). This gave me a bit of an odd: badsect: 3432631424: Result too large As the daddr_t seems to be a 64bit unsigned; I assumed that the: number = strtol(*argv, NULL, 0); was some legacy culprint - and changed it to a strtoll as the daddr_t you are entering is an int 64. number = strtoll(*argv, NULL, 0); That gets it past that point; only to segv out on: cg = dtog(fs, fsbn); /usr/include/ufs/ffs/fs.h:#define dtog(fs, d) ((d) / (fs)->fs_fpg) /usr/include/ufs/ffs/fs.h:#define dtogd(fs, d)((d) % (fs)->fs_fpg) a bit later. While fs is valid - it seems fs->fs_fpg returns as 0 why is this ? Is geom too new ? Or is badsect too old/retired ? Dw. aacd1: hard error cmd=read 4246326690-4246326721 . fsck(8):... THE FOLLOWING DISK SECTORS COULD NOT BE READ: 3432631424, 3432631425, 3432631426, 3432631427, 3432631428, 3432631429, 3432631430, 3432631431, 3432631432, 3432631433, 3432631434, 3432631435, 3432631436, 3432631437, 3432631438, 3432631439, 3432631440, 3432631441, 3432631442, 3432631443, 3432631444, 3432631445, 3432631446, 3432631447, 3432631448, 3432631449, 3432631450, 3432631451, 3432631452, 3432631453, 3432631454, 3432631455, $sudo geom label list aacd0s1d Geom name: aacd0s1d Providers: 1. Name: ufsid/4a08af657f7e3930 Mediasize: 4544528384 (4.2G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 536903168 Mode: r0w0e0 secoffset: 0 offset: 0 seclength: 8876032 length: 4544528384 index: 0 Consumers: 1. Name: aacd0s1d Mediasize: 4544528384 (4.2G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 536903168 Mode: r0w0e0 >How-To-Repeat: Run badsect with a >32 bit number. Observe it giving a Result too large >Fix: See above strtoll change -- but that uncovers another odd issue. >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/175557: commit references a PR
The following reply was made to PR kern/175557; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/175557: commit references a PR
Date: Thu, 17 Apr 2014 12:22:12 + (UTC)
Author: ae
Date: Thu Apr 17 12:22:08 2014
New Revision: 264600
URL: http://svnweb.freebsd.org/changeset/base/264600
Log:
Remove redundant unlock.
This code was removed from the opensolaris and darwin's
netsmb implementations, in DfBSD it also has been disabled.
PR: 36566, 87859, 139407, 161579, 175557, 178412, 186652
MFC after: 2 weeks
Sponsored by:Yandex LLC
Modified:
head/sys/netsmb/smb_iod.c
Modified: head/sys/netsmb/smb_iod.c
==
--- head/sys/netsmb/smb_iod.c Thu Apr 17 12:16:51 2014(r264599)
+++ head/sys/netsmb/smb_iod.c Thu Apr 17 12:22:08 2014(r264600)
@@ -87,8 +87,6 @@ smb_iod_invrq(struct smbiod *iod)
*/
SMB_IOD_RQLOCK(iod);
TAILQ_FOREACH(rqp, &iod->iod_rqlist, sr_link) {
- if (rqp->sr_flags & SMBR_INTERNAL)
- SMBRQ_SUNLOCK(rqp);
rqp->sr_flags |= SMBR_RESTART;
smb_iod_rqprocessed(rqp, ENOTCONN);
}
___
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"
bin/188726: Add "NoReverseDNS" feature
>Number: 188726
>Category: bin
>Synopsis: Add "NoReverseDNS" feature
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Thu Apr 17 12:40:00 UTC 2014
>Closed-Date:
>Last-Modified:
>Originator: Zombie Man
>Release:FreeBSD 9.1-RELEASE
>Organization:
>Environment:
>Description:
For some reason (for exammple, in home networks), DNS is not available or
improperly configured this can result in ftpd blocking ("stalling") until the
libc resolver code times out. Using NoReverseDNS (-N command line option) will
solve this problem.
>How-To-Repeat:
>Fix:
patch file attached
Patch attached with submission follows:
Index: extern.h
===
--- extern.h(revision 264526)
+++ extern.h(working copy)
@@ -97,6 +97,7 @@
extern int type;
extern char *typenames[]; /* defined in included from ftpd.c */
extern int usedefault;
+extern int NoReverseDNS;
struct sockaddr_in;
struct sockaddr_in6;
Index: ftpd.8
===
--- ftpd.8 (revision 264526)
+++ ftpd.8 (working copy)
@@ -36,7 +36,7 @@
.Nd Internet File Transfer Protocol server
.Sh SYNOPSIS
.Nm
-.Op Fl 468ADdEhMmOoRrSUvW
+.Op Fl 468ADdEhMmNOoRrSUvW
.Op Fl l Op Fl l
.Op Fl a Ar address
.Op Fl P Ar port
@@ -133,6 +133,9 @@
existing files if allowed by file system permissions.
By default, anonymous users cannot modify existing files;
in particular, files to upload will be created under a unique name.
+.It Fl N
+Disable reverse DNS lookup for clients (useful for home LAN's without DNS).
+All client addresses logged in dotted form.
.It Fl O
Put server in write-only mode for anonymous users only.
RETR is disabled for anonymous users, preventing anonymous downloads.
Index: ftpd.c
===
--- ftpd.c (revision 264526)
+++ ftpd.c (working copy)
@@ -140,6 +140,7 @@
intnoguestretr = 0;/* RETR command is disabled for anon users. */
intnoguestmkd = 0; /* MKD command is disabled for anon users. */
intnoguestmod = 1; /* anon users may not modify existing files. */
+intNoReverseDNS; /* 0 = do reverse DNS lookup for clients */
off_t file_size;
off_t byte_count;
@@ -301,7 +302,7 @@
openlog("ftpd", LOG_PID | LOG_NDELAY, LOG_FTP);
while ((ch = getopt(argc, argv,
- "468a:AdDEhlmMoOp:P:rRSt:T:u:UvW")) != -1) {
+ "468a:AdDEhlmMNoOp:P:rRSt:T:u:UvW")) != -1) {
switch (ch) {
case '4':
family = (family == AF_INET6) ? AF_UNSPEC : AF_INET;
@@ -351,6 +352,10 @@
noguestmkd = 1;
break;
+ case 'N':
+ NoReverseDNS = 1;
+ break;
+
case 'o':
noretr = 1;
break;
@@ -2715,11 +2720,16 @@
{
char who_name[NI_MAXHOST];
- realhostname_sa(remotehost, sizeof(remotehost) - 1, who, who->sa_len);
- remotehost[sizeof(remotehost) - 1] = 0;
- if (getnameinfo(who, who->sa_len,
- who_name, sizeof(who_name) - 1, NULL, 0, NI_NUMERICHOST))
- *who_name = 0;
+ if (NoReverseDNS) {
+ if (getnameinfo(who, who->sa_len, remotehost,
sizeof(remotehost)-1, NULL, 0, NI_NUMERICHOST))
+ *remotehost = 0;
+ }
+ else
+ realhostname_sa(remotehost, sizeof(remotehost)-1, who,
who->sa_len);
+ remotehost[sizeof(remotehost)-1] = 0;
+
+ if (getnameinfo(who, who->sa_len, who_name, sizeof(who_name)-1, NULL,
0, NI_NUMERICHOST))
+ *who_name = 0;
who_name[sizeof(who_name) - 1] = 0;
#ifdef SETPROCTITLE
Index: logwtmp.c
===
--- logwtmp.c (revision 264526)
+++ logwtmp.c (working copy)
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
#include
@@ -60,9 +61,12 @@
/* Log in. */
ut.ut_type = USER_PROCESS;
(void)strncpy(ut.ut_user, user, sizeof(ut.ut_user));
- if (addr != NULL)
- realhostname_sa(ut.ut_host, sizeof(ut.ut_host),
- addr, addr->sa_len);
+ if (addr != NULL) {
+ if (NoReverseDNS)
+ getnameinfo(addr, addr->sa_len, ut.ut_host,
sizeof(ut.ut_host)-1, NULL, 0, NI_NUMERICHOST);
+ else
+ realhostname_sa(ut.ut_host, sizeof(ut.ut_host),
addr, addr->sa_len);
+
Re: bin/188715: int64 not handled right as arg on badsect(8), possible other issues lurking
On Thu, 17 Apr 2014, Dirk-Willem van Gulik wrote: Description: Was trying to map out some bad blocks prior to temporarily read/empty 4 Tbyte volume using ?badsect(8)? - and returing it. Was expecting to be able to put the sector # into badsect (e.g. 3432631424 from below FSCK output). This gave me a bit of an odd: badsect: 3432631424: Result too large badsect's ABI uses mknod() and dev_t so it can only work up to 32 bits. (Before 4.4BSD, dev_t was only 16 bits, so badsect only works up to 16 bits. That is a whole 65536 sectors, or 33MB with 512-blocks. This was almost enough in 1980. However, the limit is on fs-blocks (fragments), not on 512-blocks, so the limit can be expanded a bit. With the current default ffs block size of 32K, the fragment size is 4K, so the limit in 1984 would have been 256MB. However, the default fragment size was 512 until about 1995.) It also has bugs in its error checking, so it only works up to 31 bits on arches with 32-bit longs. The above is one of them. 3432631424 doesn't fit in 31 bits, but it does fit in 32 bits. The bugs in the error checking are more serious than I thought, since the limit is on 512-blocks. So on arches with 32-bit longs, the limit on the file system size is 2**31 * 2**9 = 1TB. With 4K-frags it should be 2**32 * 2**12 = 16TB, so badsect should actually work on your 4TB file system. It shouldn't be expected to work. 4TB disks are supposed to be replaced if they have a single uncorrectable error. There are related limits on file system size from the file system itself. ffs1 uses 32-bit signed block (fragment) numbers internally, so it shouldn't be affected by the 332-bit badsect ABI limit. As the daddr_t seems to be a 64bit unsigned; I assumed that the: daddr_t is 64 bits signed. number = strtol(*argv, NULL, 0); was some legacy culprint - and changed it to a strtoll as the daddr_t you are entering is an int 64. daddr_t used to be 32-bit signed, and badsect hasn't been maintained since before daddr_t became 64 bits. Even 1GB disks are supposed to be replaced if they have a single uncorrectable error. number = strtoll(*argv, NULL, 0); Ugh. Long long should never be used. Use intmax_t. badsect's buggy error checking involves many type errors. It uses the system type daddr_t for 'number'. This is correct. But it also uses long, and in the above, long long, and in the clean version, intmax_t, for initializing 'number'. I neglected to fix this when I updated badsect from 16 bits to 32 bits in 1995. The update was incomplete. The result of strtoimax() should be assigned to a variable of type intmax_t. It shouldn't be assigned to 'number' before checking that it fits. The type errors continue with badsect abusing daddr_t for the disk block number. That was as correct as possible in 1994, and also in my fixes, because ffs also used this wrong type internally. ffs now uses ufs_daddr1_t and ufs_daddr_t internally. daddr_t would work in badsect since it is 64 bits signed and only 32 bits unsigned is needed, but it is logically wrong. That gets it past that point; only to segv out on: cg = dtog(fs, fsbn); /usr/include/ufs/ffs/fs.h:#define dtog(fs, d) ((d) / (fs)->fs_fpg) /usr/include/ufs/ffs/fs.h:#define dtogd(fs, d)((d) % (fs)->fs_fpg) a bit later. While fs is valid - it seems fs->fs_fpg returns as ?0? ? why is this ? Is geom too new ? Or is badsect too old/retired ? I don't see why that doesn't work. fsdb is the fs-block (frag) number, and the types are now large enough although logically wrong. Some of the differences for ffs2 are in macros, but the above macros are too simple to depend on the ffs version. Maybe libufs messes up the initialization of all of 'fs'. aacd1: hard error cmd=read 4246326690-4246326721 . fsck(8):... THE FOLLOWING DISK SECTORS COULD NOT BE READ: 3432631424, 3432631425, 3432631426, 3432631427, 3432631428, 3432631429, 3432631430, 3432631431, 3432631432, 3432631433, 3432631434, 3432631435, 3432631436, 3432631437, 3432631438, 3432631439, 3432631440, 3432631441, 3432631442, 3432631443, 3432631444, 3432631445, 3432631446, 3432631447, 3432631448, 3432631449, 3432631450, 3432631451, 3432631452, 3432631453, 3432631454, 3432631455, Perhaps too many for badsect. I haven't used badsect recently, but spent a lot of time rearranging whole partitions on a laptop drive to avoid a 20GB area with a few bad sectors. The rest of the disk worked suprisingly well. Bruce___ 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/188715: int64 not handled right as arg on badsect(8), possible other issues lurking
The following reply was made to PR bin/188715; it has been noted by GNATS. From: Bruce Evans To: Dirk-Willem van Gulik Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: bin/188715: int64 not handled right as arg on badsect(8), possible other issues lurking Date: Thu, 17 Apr 2014 23:43:03 +1000 (EST) This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1210473500-1397742183=:1829 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 17 Apr 2014, Dirk-Willem van Gulik wrote: >> Description: > Was trying to map out some bad blocks prior to temporarily read/empty 4 T= byte volume using =82badsect(8)=92 - and returing it. > > Was expecting to be able to put the sector # into badsect (e.g. 343263142= 4 from below FSCK output). > > This gave me a bit of an odd: > > =09badsect: 3432631424: Result too large badsect's ABI uses mknod() and dev_t so it can only work up to 32 bits. (Before 4.4BSD, dev_t was only 16 bits, so badsect only works up to 16 bits. That is a whole 65536 sectors, or 33MB with 512-blocks. This was almost enough in 1980. However, the limit is on fs-blocks (fragments), not on 512-blocks, so the limit can be expanded a bit. With the current default ffs block size of 32K, the fragment size is 4K, so the limit in 1984 would have been 256MB. However, the default fragment size was 512 until about 1995.) It also has bugs in its error checking, so it only works up to 31 bits on arches with 32-bit longs. The above is one of them. 3432631424 doesn't fit in 31 bits, but it does fit in 32 bits. The bugs in the error checking are more serious than I thought, since the limit is on 512-blocks. So on arches with 32-bit longs, the limit on the file system size is 2**31 * 2**9 =3D 1TB. With 4K-frags it should be 2**32 * 2**12 =3D 16TB, so badsect should actually work on your 4TB file system. It shouldn't be expected to work. 4TB disks are supposed to be replaced if they have a single uncorrectable error. There are related limits on file system size from the file system itself. ffs1 uses 32-bit signed block (fragment) numbers internally, so it shouldn'= t be affected by the 332-bit badsect ABI limit. > As the daddr_t seems to be a 64bit unsigned; I assumed that the: daddr_t is 64 bits signed. > > =09=09=09number =3D strtol(*argv, NULL, 0); > > was some legacy culprint - and changed it to a strtoll as the daddr_t you= are entering is an int 64. daddr_t used to be 32-bit signed, and badsect hasn't been maintained since before daddr_t became 64 bits. Even 1GB disks are supposed to be replaced if they have a single uncorrectable error. > =09=09=09number =3D strtoll(*argv, NULL, 0); Ugh. Long long should never be used. Use intmax_t. badsect's buggy error checking involves many type errors. It uses the system type daddr_t for 'number'. This is correct. But it also uses long, and in the above, long long, and in the clean version, intmax_t, for initializing 'number'. I neglected to fix this when I updated badsect from 16 bits to 32 bits in 1995. The update was incomplete. The result of strtoimax() should be assigned to a variable of type intmax_t. It shouldn't be assigned to 'number' before checking that it fits. The type errors continue with badsect abusing daddr_t for the disk block number. That was as correct as possible in 1994, and also in my fixes, because ffs also used this wrong type internally. ffs now uses ufs_daddr1_= t and ufs_daddr_t internally. daddr_t would work in badsect since it is 64 bits signed and only 32 bits unsigned is needed, but it is logically wrong. > That gets it past that point; only to segv out on: > > cg =3D dtog(fs, fsbn); > > =09/usr/include/ufs/ffs/fs.h:#define=09dtog(fs, d)=09((d) / (fs)->fs_fpg) > =09/usr/include/ufs/ffs/fs.h:#define=09dtogd(fs, d)=09((d) % (fs)->fs_fpg= ) > > a bit later. While fs is valid - it seems fs->fs_fpg returns as =820=92= =97 why is this ? Is geom too new ? Or is badsect too old/retired ? I don't see why that doesn't work. fsdb is the fs-block (frag) number, and the types are now large enough although logically wrong. Some of the differences for ffs2 are in macros, but the above macros are too simple to depend on the ffs version. Maybe libufs messes up the initialization of all of 'fs'. > aacd1: hard error cmd=3Dread 4246326690-4246326721 > . > > fsck(8):... > THE FOLLOWING DISK SECTORS COULD NOT BE READ: 3432631424, 3432631425, 343= 2631426, 3432631427, 3432631428, 3432631429, 3432631430, 3432631431, 343263= 1432, 3432631433, 3432631434, 3432631435, 3432631436, 3432631437, 343263143= 8, 3432631439, 3432631440, 3432631441, 3432631442, 3432631443, 3432631444, = 3432631445, 3432631446, 3432631447, 3
Re: kern/173337: clang kernel cross-builds ignore CPUTYPE?= and always generate native tuned code
Thank you for asking. I don't have access to the target platform to test it. Please close the PR. On 04/17/2014 00:27, lini...@freebsd.org wrote: > Synopsis: clang kernel cross-builds ignore CPUTYPE?= and always generate > native tuned code > > State-Changed-From-To: open->feedback > State-Changed-By: linimon > State-Changed-When: Thu Apr 17 04:27:08 UTC 2014 > State-Changed-Why: > to submitter: xdev has recently been reworked. Is this PR now obsolete? > > > Responsible-Changed-From-To: freebsd-bugs->linimon > Responsible-Changed-By: linimon > Responsible-Changed-When: Thu Apr 17 04:27:08 UTC 2014 > Responsible-Changed-Why: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=173337 > signature.asc Description: OpenPGP digital signature
Re: kern/175670: [iscsi] smartctl fails on SAS disk connected to an Intel C600 controller (isci driver)
On 14-04-17 12:19 AM, lini...@freebsd.org wrote: Old Synopsis: smartctl fails on SAS disk connected to an Intel C600 controller (isci driver) New Synopsis: [iscsi] smartctl fails on SAS disk connected to an Intel C600 controller (isci driver) Responsible-Changed-From-To: freebsd-bugs->freebsd-scsi Responsible-Changed-By: linimon Responsible-Changed-When: Thu Apr 17 04:18:15 UTC 2014 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=175670 I have one of those disks and it works for me in: FreeBSD 10.0-RELEASE #0 r260789 # smartctl -i /dev/pass2 smartctl 6.3 2014-04-10 r3888 [FreeBSD 10.0-RELEASE i386] (local build) Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Vendor: SEAGATE Product: ST33000650SS Revision: 0002 User Capacity:3,000,592,982,016 bytes [3.00 TB] Logical block size: 512 bytes Formatted with type 1 protection Rotation Rate:7200 rpm Form Factor: 3.5 inches Logical Unit id: 0x5000c5003311 Serial number:9XK0JN6Z Device type: disk Transport protocol: SAS Local Time is:Thu Apr 17 12:36:57 2014 EDT SMART support is: Available - device has SMART capability. SMART support is: Enabled Temperature Warning: Enabled This was built from the latest smartmontools developer repository because the FreeBSD ports version of smartmontool was broken, see below. The reporter had Revision 4 of the disk's firmware while mine is Revision 2. The reported error said the IEC mode page was broken. No surprise there, mine is too but in a different way: [root@sas ~]# sg_modes -p 0x1c /dev/pass2 SEAGATE ST33000650SS 0002 peripheral_type: disk [0x0] Mode parameter header from MODE SENSE(10): Mode data length=28, medium type=0x00, WP=0, DpoFua=1, longlba=0 Block descriptor length=8 > Direct access device block descriptors: Density code=0x0 00 ff ff ff ff 00 00 02 00 >> Informational exceptions control, page_control: current 00 9c 0a 10 00 00 00 00 00 00 00 00 01 [root@sas ~]# sg_modes -p 0x1c -L /dev/pass2 SEAGATE ST33000650SS 0002 peripheral_type: disk [0x0] Mode parameter header from MODE SENSE(10): Mode data length=36, medium type=0x00, WP=0, DpoFua=1, longlba=1 Block descriptor length=16 > longlba direct access device block descriptors: Density code=0x0 00 00 00 00 01 5d 50 a3 b0 00 00 00 00 00 >> Informational exceptions control, page_control: current 00 9c 0a 10 00 00 00 00 00 00 00 00 01 The long LBA version says the logical block size is 0 bytes. Well done Seagate! So IMO this is not a FreeBSD error and most likely not a smartmontools error. Also it has nothing to do with the HBA. But I did see this when I tried to build smartmontools from ports: [root@sas /usr/ports/sysutils/smartmontools]# make install make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: duplicate script for target "-depends" ignored make: "/usr/ports/Mk/bsd.port.mk" line 5118: warning: using previous script for "-depends" defined here make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: duplicate script for target "-depends" ignored make: "/usr/ports/Mk/bsd.port.mk" line 5118: warning: using previous script for "-depends" defined here make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: duplicate script for target "-depends" ignored make: "/usr/ports/Mk/bsd.port.mk" line 5118: warning: using previous script for "-depends" defined here make: "/usr/ports/Mk/bsd.port.mk" line 5118: warning: duplicate script for target "-depends" ignored make: "/usr/ports/Mk/bsd.port.mk" line 5118: warning: using previous script for "-depends" defined here make: "/usr/ports/Mk/bsd.port.mk" line 5121: warning: duplicate script for target "-depends" ignored make: "/usr/ports/Mk/bsd.port.mk" line 5118: warning: using previous script for "-depends" defined here ===> smartmontools-6.0 improper use of USE_PERL5. *** Error code 1 Stop. make: stopped in /usr/ports/sysutils/smartmontools Doug Gilbert ___ 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: Solarflare LACP bug?
On Wed, Apr 16, 2014 at 7:01 PM, aurfalien wrote: > Hi, > > I’ve a Solarflare SFN5162F dual port 10Gb ethernet adapter. > > While the card works fine as individual ports, upon configuring LACP the > machine suddenly reboots. > > Here are my commands; > > ifconfig sfxge0 up > ifconfig sfxge1 up > ifconfig lagg0 create > * ifconfig lagg0 up laggproto lacp laggport sfxge0 laggport sfxge1 > 10.0.10.99/16 > > * This is were the system reboots. > > I believe this to be a bug, what other info can I supply to help determine if > it is or simply user error? I do not know much about LACP or solarflare but you can start with following and someone with more knowledge in that area will help you: - FreeBSD version you are using - uname -a - ifconfig output - Any errors you see in /var/log/messages or dmesg. - turn on any debugging knobs available with your card drivers cheers, Hiren ___ 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/188745: FreeBSD base OpenSSL puts private keys to RNG seeds
>Number: 188745 >Category: bin >Synopsis: FreeBSD base OpenSSL puts private keys to RNG seeds >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: Fri Apr 18 04:00:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Kenji Rikitake >Release:10.0-STABLE >Organization: >Environment: FreeBSD minimax.priv.k2r.org 10.0-STABLE FreeBSD 10.0-STABLE #33 r264285: Wed Apr 9 09:25:02 JST 2014 r...@minimax.priv.k2r.org:/usr/obj/usr/src/sys/K2RKERNEL amd64 >Description: OpenBSD devs report OpenSSL puts RSA private keys as they are for seeding the PRNG. See http://freshbsd.org/commit/openbsd/e5136d69ece4682e6167c8f4a8122270236898bf for the details. On 10.0-STABLE, I've found the same practice under /usr/src/crypto/openssl/crypto at: rsa/rsa_crpt.c 229: RAND_add(rsa->d->d, rsa->d->dmax * sizeof rsa->d->d[0], 0.0); evp/evp_pkey.c 153: RAND_add(p8->pkey->value.octet_string->data, pem/pem_lib.c 391: RAND_add(data,i,0);/* put in the RSA key. */ >How-To-Repeat: Recompile the userland. (Note: the similar source code may exist in the Port OpenSSL too) >Fix: OpenBSD team has already removed the problematic code as described in http://freshbsd.org/commit/openbsd/e5136d69ece4682e6167c8f4a8122270236898bf I think the same security audit on FreeBSD is seriously required. >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"
