misc/172086: reboot hang with 'All buffers synced' after freebsd-update FreeBSD9 to p3 on ZFS root
>Number: 172086 >Category: misc >Synopsis: reboot hang with 'All buffers synced' after freebsd-update >FreeBSD9 to p3 on ZFS root >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 Sep 26 08:50:06 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Marek >Release:9.0 >Organization: none >Environment: default freebsd 9.0 install, generic kernel (sorry, don't have access to machine at this time to fetch uname output). >Description: I have a problem with FreeBSD 9-RELEASE installed on ZFS mirror file system using tips from here: http://wiki.freebsd.org/RootOnZFS/GP...ot/9.0-RELEASE Immediately after installation I'm inovking: # freebsd-update fetch # freebsd-update install Update is always successfull, but when I invoke: # reboot / # shutdown -r / # halt / # poweroff / etc. system will try to reboot, but will stop on the All buffers synced message. The funny thing is that the server is responding to ping's, prints messages if I attach USB stick etc. This problem doesn't take place if FreeBSD is installed "normally", on UFS. Also it doesn't occurs when I remove 'world' from Components in /etc/freebsd-update.conf (so the line looks like this): Components src kernel The problem also occurs when I invoke # freebsd-update rollback The interesting fact is that after invoking the 'freebsd-update fetch' we get list of files to be updated with information: The following files will be updated as part of updating to 9.0-RELEASE-p4 but after reboot we've go the -p3 version. --- I searched a lot, but found nothing related to freebsd-update. Thank you for your time, Marek >How-To-Repeat: The problem is very easy to reproduce: Just create Virtual Machine in VirtualBox with two disks, install using instructions I have used (http://wiki.freebsd.org/RootOnZFS/GP...ot/9.0-RELEASE), after installation reboot, login as root, invoke: # freebsd-update fetch # freebsd-update install # reboot >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: bin/161548: [patch] getent(1) inconsistent treatment of IPv6 host data
Synopsis: [patch] getent(1) inconsistent treatment of IPv6 host data State-Changed-From-To: open->closed State-Changed-By: kevlo State-Changed-When: Wed Sep 26 09:30:19 UTC 2012 State-Changed-Why: Committed, thanks. http://www.freebsd.org/cgi/query-pr.cgi?pr=161548 ___ 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/161548: commit references a PR
The following reply was made to PR bin/161548; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: bin/161548: commit references a PR
Date: Wed, 26 Sep 2012 09:31:29 + (UTC)
Author: kevlo
Date: Wed Sep 26 09:29:48 2012
New Revision: 240954
URL: http://svn.freebsd.org/changeset/base/240954
Log:
Teach getent(1) to look up a hostname and find IPv6 addresses.
PR: bin/161548
Submitted by:matthew
Modified:
head/usr.bin/getent/getent.c
Modified: head/usr.bin/getent/getent.c
==
--- head/usr.bin/getent/getent.c Wed Sep 26 09:27:38 2012
(r240953)
+++ head/usr.bin/getent/getent.c Wed Sep 26 09:29:48 2012
(r240954)
@@ -277,7 +277,7 @@ hostsprint(const struct hostent *he)
static int
hosts(int argc, char *argv[])
{
- struct hostent *he;
+ struct hostent *he4, *he6;
charaddr[IN6ADDRSZ];
int i, rv;
@@ -285,21 +285,31 @@ hosts(int argc, char *argv[])
assert(argv != NULL);
sethostent(1);
+ he4 = he6 = NULL;
rv = RV_OK;
if (argc == 2) {
- while ((he = gethostent()) != NULL)
- hostsprint(he);
+ while ((he4 = gethostent()) != NULL)
+ hostsprint(he4);
} else {
for (i = 2; i < argc; i++) {
- if (inet_pton(AF_INET6, argv[i], (void *)addr) > 0)
- he = gethostbyaddr(addr, IN6ADDRSZ, AF_INET6);
- else if (inet_pton(AF_INET, argv[i], (void *)addr) > 0)
- he = gethostbyaddr(addr, INADDRSZ, AF_INET);
- else
- he = gethostbyname(argv[i]);
- if (he != NULL)
- hostsprint(he);
- else {
+ if (inet_pton(AF_INET6, argv[i], (void *)addr) > 0) {
+ he6 = gethostbyaddr(addr, IN6ADDRSZ, AF_INET6);
+ if (he6 != NULL)
+ hostsprint(he6);
+ } else if (inet_pton(AF_INET, argv[i],
+ (void *)addr) > 0) {
+ he4 = gethostbyaddr(addr, INADDRSZ, AF_INET);
+ if (he4 != NULL)
+ hostsprint(he4);
+ } else {
+ he6 = gethostbyname2(argv[i], AF_INET6);
+ if (he6 != NULL)
+ hostsprint(he6);
+ he4 = gethostbyname(argv[i]);
+ if (he4 != NULL)
+ hostsprint(he4);
+ }
+ if ( he4 == NULL && he6 == NULL ) {
rv = RV_NOTFOUND;
break;
}
___
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"
misc/172089: databases/postgresql92-server change periodic script [patch]
>Number: 172089
>Category: misc
>Synopsis: databases/postgresql92-server change periodic script [patch]
>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 Sep 26 12:10:03 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Dmitry
>Release:9.1-PRERELEASE
>Organization:
-
>Environment:
FreeBSD *** 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0 r240914: ***
root@***:/usr/obj/usr/src/sys/GENERIC_ amd64
>Description:
periodic script not allow configure pgsql user and port
>How-To-Repeat:
>Fix:
Patch attached with submission follows:
--- files/502.pgsql.in.orig 2011-10-18 15:03:32.0 +0600
+++ files/502.pgsql.in 2012-09-26 17:48:27.0 +0600
@@ -19,14 +19,6 @@
# daily_pgsql_backup_enable="foo bar db1 db2" # only do backup of a limited
selection of databases
# daily_pgsql_vacuum_enable="YES" # do vacuum
-daily_pgsql_user=%%PG_USER%%
-daily_pgsql_vacuum_args="-U ${daily_pgsql_user} -qaz"
-daily_pgsql_pgdump_args="-U ${daily_pgsql_user} -bF c"
-daily_pgsql_pgdumpall_globals_args="-U ${daily_pgsql_user}"
-# backupdir is relative to ~pgsql home directory unless it begins with a slash:
-daily_pgsql_backupdir="~${daily_pgsql_user}/backups"
-daily_pgsql_savedays="7"
-
# If there is a global system configuration file, suck it in.
#
if [ -r /etc/defaults/periodic.conf ]
@@ -35,6 +27,15 @@
source_periodic_confs
fi
+daily_pgsql_user=${daily_pgsql_user:-"%%PG_USER%%"}
+daily_pgsql_port=${daily_pgsql_port:-"5432"}
+daily_pgsql_vacuum_args="-U ${daily_pgsql_user} -p ${daily_pgsql_port} -qaz"
+daily_pgsql_pgdump_args="-U ${daily_pgsql_user} -p ${daily_pgsql_port} -bF c"
+daily_pgsql_pgdumpall_globals_args="-U ${daily_pgsql_user} -p
${daily_pgsql_port}"
+# backupdir is relative to ~pgsql home directory unless it begins with a slash:
+daily_pgsql_backupdir="~${daily_pgsql_user}/backups"
+daily_pgsql_savedays="7"
+
# allow '~ยด in dir name
eval backupdir=${daily_pgsql_backupdir}
@@ -82,7 +83,7 @@
case "$daily_pgsql_backup_enable" in
[Yy][Ee][Ss])
- dbnames=`su -l %%PG_USER%% -c "umask 077; psql -q -t -A -d template1 -U
%%PG_USER%% -c SELECT\ datname\ FROM\ pg_database\ WHERE\
datname!=\'template0\'"`
+ dbnames=`su -l ${daily_pgsql_user} -c "umask 077; psql -U
${daily_pgsql_user} -p ${daily_pgsql_port} -q -t -A -d template1 -c SELECT\
datname\ FROM\ pg_database\ WHERE\ datname!=\'template0\'"`
pgsql_backup $dbnames
;;
>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/172091: Improvements to mfi support including foreign disks / configs in mfiutil
>Number: 172091
>Category: misc
>Synopsis: Improvements to mfi support including foreign disks / configs
>in mfiutil
>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 Sep 26 12:40:06 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Steven Hartland
>Release:8.3-RELEASE
>Organization:
Multiplay
>Environment:
FreeBSD dev 8.3-RELEASE-p4 FreeBSD 8.3-RELEASE-p4 #22: Mon Sep 17 17:18:32 UTC
2012 root@dev:/usr/obj/usr/src/sys/MULTIPLAY amd64
>Description:
Currently mfiutil lacks support for foreign disks.
Along with the missing functionality this also causes confusing errors to be
returned when using otherwise good disks with other commands as can be seen in
the following PR:
http://www.freebsd.org/cgi/query-pr.cgi?pr=157293
When run under a debug kernel a MFI_DCMD_CFG_FOREIGN_IMPORT call from user
space will cause a panic:
Lock MFI config not exclusively locked @ /usr/src/sys/dev/mfi/mfi.c:1001
When a long running command operates a timeout error is generated. The current
timeout is hardcoded at 30 seconds which isn't always long enough for
operations such as secure erase.
>How-To-Repeat:
1. Try to work with foreign configurations / disks under mfi.
2. Make a MFI_DCMD_CFG_FOREIGN_IMPORT call from user space under a debug kernel
3. Run a controller command which takes more than 30 seconds, a timeout will be
generated.
>Fix:
The attached patch fixes all these issue.
It adds support for foreign disks / configs this implements the following new
methods to mfiutil
* foreign scan - lists the number of foreign configs
* foreign drives - lists the drives which are flagged as foreign
* foreign display - displays the specified foreign configuration
* foreign preview - previews the specified foreign configuration (after import)
* foreign clear - clears the foreign configuration
* foreign import - imports the foreign configuration
mfiutil show drives - now identifies foreign drives
It should be noted that although foreign import takes a configuration option
this currently fails with error code 0x03 (invalid argument). This also
occurs with MegaCli so its currently thought this is a firmware bug.
Fixes a panic when MFI_DCMD_CFG_FOREIGN_IMPORT is called from user space.
Adds hw.mfi.cmd_timeout loader / sysctl tuneable which controls the default
timeout used in the mfi driver. This is useful for long running commands
such as secure erase.
Additional debugging of DCMD commands has also been added which added
identifying the DCMD's used by MegaCli to perform the various actions.
Patch attached with submission follows:
Add support for foreign disks / configs this implements the following new
methods to mfiutil
* foreign scan - lists the number of foreign configs
* foreign drives - lists the drives which are flagged as foreign
* foreign display - displays the specified foreign configuration
* foreign preview - previews the specified foreign configuration (after import)
* foreign clear - clears the foreign configuration
* foreign import - imports the foreign configuration
mfiutil show drives - now identifies foreign drives
It should be noted that although foreign import takes a configuration option
this currently fails with error code 0x03 (invalid argument). This also
occurs with MegaCli so its currently thought this is a firmware bug.
Fixes a panic when MFI_DCMD_CFG_FOREIGN_IMPORT is called from user space.
Adds hw.mfi.cmd_timeout loader / sysctl tuneable which controls the default
timeout used in the mfi driver. This is useful for long running commands
such as secure erase.
Additional debugging of DCMD commands has also been added which added
identifying the DCMD's used by MegaCli to perform the various actions.
--- usr.sbin/mfiutil/Makefile.orig 2012-03-03 06:15:13.0 +
+++ usr.sbin/mfiutil/Makefile 2012-09-21 15:52:24.648147593 +
@@ -2,7 +2,7 @@
PROG= mfiutil
SRCS= mfiutil.c mfi_cmd.c mfi_config.c mfi_drive.c mfi_evt.c mfi_flash.c \
- mfi_patrol.c mfi_show.c mfi_volume.c
+ mfi_patrol.c mfi_show.c mfi_volume.c mfi_foreign.c
MAN8= mfiutil.8
CFLAGS+= -fno-builtin-strftime
--- usr.sbin/mfiutil/mfi_cmd.c.orig 2012-03-03 06:15:13.0 +
+++ usr.sbin/mfiutil/mfi_cmd.c 2012-09-24 13:22:53.204020111 +
@@ -284,7 +284,7 @@
if (statusp != NULL)
*statusp = dcmd->header.cmd_status;
else if (dcmd->header.cmd_status != MFI_STAT_OK) {
- warnx("Command failed: %s",
+ warnx("Command 0x%08x failed: %s", opcode,
mfi_status(dcmd->header.cmd_status));
errno = EIO;
return (-1);
--- usr.sbin/mfiutil/mfi_config.c.orig 2012-03-03 06:15:13.0 +
+++ usr.sbin/mfiutil/mfi_config.c 2012-09-24 16:39:46.85631
kern/172092: zfs import panics kernel
>Number: 172092 >Category: kern >Synopsis: zfs import panics kernel >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 Sep 26 12:50:15 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Oliver Adler >Release:9.0-RELEASE-p3 >Organization: N/A >Environment: FreeBSD i5.a999.de 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0: Tue Jun 12 02:52:29 UTC 2012 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 >Description: Using a 2.5" external USB 3.0 disk with 750 GB. On the disk is a bootable 9.0 FBSD. The disk was used as boot disk on a i386 atom system. Then using it on a amd64 system with zpool import -o altroot=/mnt -f zroot orked fine. After shutting down the system with shutdown -p now the disk can no more be used. Issuing zpool list or zpool import -o altroot=/mnt -f zroot on the amd64 system panics the kernel. Also attaching the device to the i386 system panics the atom system. The failed assertion is in the file ddt.c line 129. I have a picture of the panic. My assumption is, that there is a problem with deduplication (because on the disk is one dataset with switched on dedup). The data of the disk is no more accessible. >How-To-Repeat: Using this disk, plugging it to either the amd64 or the i386 system Issuing zpool list and the panic shows up If you have any patches to test I will do this. I will keep the disk in this state for some time. If I can help in any way, please ask me. >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/157293: [mfi] mfiutil/mfi does not allow adding a previously configured drive to be added to a new array
The following reply was made to PR kern/157293; it has been noted by GNATS. From: "Steven Hartland" To: , "Jonathan" Cc: Subject: Re: kern/157293: [mfi] mfiutil/mfi does not allow adding a previously configured drive to be added to a new array Date: Wed, 26 Sep 2012 13:59:52 +0100 I believe the cause of your issue is that the disks where marked as "foreign". This doesn't mean they are bad but the controller won't let you import, add etc as it thinks they are already a part of another array, so its just being safe. I've just finished off some updates to mfiutil which will both detect this and allow you to "fix" them. The PR for these fixes includes the patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=172091 This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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/171865: [geom] g_wither_washer() keeping a core busy
The following reply was made to PR kern/171865; it has been noted by GNATS. From: Fabian Keil To: Jaakko Heinonen Cc: bug-follo...@freebsd.org, lu...@freebsd.org Subject: Re: kern/171865: [geom] g_wither_washer() keeping a core busy Date: Wed, 26 Sep 2012 17:41:16 +0200 --Sig_/9Up1jT9Q9Fv4+b.oSjPAz2= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Jaakko Heinonen wrote: > On 2012-09-22, Fabian Keil wrote: > > I recently found a way to reproduce the problem without using > > ZFS or writing to the device. > > >How-To-Repeat: > > geli onetime /dev/md0 > > geom sched insert -a rr /dev/md0.eli > > geli detach /dev/md0.eli.sched. >=20 > It seems that if you "insert" a sched geom and do "geli detach" on it, > the geli geom can't be destroyed. >=20 > After your commands "md0.eli" still exists: =20 > I didn't find a way to destroy it. I suspect a geom_sched bug. luigi@ > cc'd. While I can't rule out a geom_sched bug, I usually run into the problem while only using glabel+geli+ZFS on an USB device that disappears as described in the initial report at: http://lists.freebsd.org/pipermail/freebsd-fs/2011-June/011855.html It's just less convenient to reproduce as it requires more steps and the disappearance can also lead to panics like these: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/162010 http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/162036 Fabian --Sig_/9Up1jT9Q9Fv4+b.oSjPAz2= Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBjIiAACgkQSMVSH78upWM/pQCfd7TY7/GOblu08UXFUzF2XDNP Y9gAnjXvGj4MkFFGmamXTlsP6mkwiGiJ =XXQN -END PGP SIGNATURE- --Sig_/9Up1jT9Q9Fv4+b.oSjPAz2=-- ___ 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/172096: sysinstall does not support new DEBUG kernel distribution in 8.x
>Number: 172096
>Category: bin
>Synopsis: sysinstall does not support new DEBUG kernel distribution in
>8.x
>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 Sep 26 19:20:04 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Devin Teske
>Release:FreeBSD 8.3-RELEASE-p1 amd64
>Organization:
FIS Global, Inc.
>Environment:
FreeBSD scu83a.dev.vicor.com 8.3-RELEASE-p1 FreeBSD 8.3-RELEASE-p1 #2: Tue May
29 18:37:14 PDT 2012
dte...@push830-64.vicor.com:/usr/src/sys/amd64/compile/FIS-amd64 amd64
>Description:
>From Rick Miller via -questions:
I performed a `make release` with FreeBSD 8.3p4 sources that built a secondary
kernel (called DEBUG). It ended up in the release inside kernels/ as expected.
The install.cfg file includes the line:
dists=base kernels GENERIC SMP DEBUG doc catpages
DEBUG was added to the above along with the new release build. All
distributions get installed with the exception of DEBUG. In looking through the
sysinstall sources [...] it appears as though the sources need to be modified
to support a new DEBUG distribution.
(end quote)
This has been confirmed and the attached patch.txt addresses this, adding the
DEBUG kernel distribition to the list of selectable (either via menu or via
install.cfg) kernels.
>How-To-Repeat:
Produce installation media under RELENG_8 using release(7). Attempt to craft an
automated installer that installs the new DEBUG kernel distribution. Fail
(DEBUG kernel distribution not installed as desired because code lacks
knowledge of this new dist-set).
>Fix:
See attached patch.txt adding support for this new dist-set.
Patch attached with submission follows:
Index: dist.c
===
--- dist.c (revision 240968)
+++ dist.c (working copy)
@@ -102,6 +102,7 @@ static Distribution KernelDistTable[] = {
#ifdef WITH_SMP
DTE_TARBALL("SMP", &KernelDists, KERNEL_SMP, "/boot"),
#endif
+DTE_TARBALL("DEBUG",&KernelDists, KERNEL_DEBUG, "/boot"),
DTE_END,
};
Index: dist.h
===
--- dist.h (revision 240968)
+++ dist.h (working copy)
@@ -73,6 +73,7 @@
/* Subtypes for KERNEL distribution */
#define DIST_KERNEL_GENERIC0x1
#define DIST_KERNEL_SMP0x2
+#define DIST_KERNEL_DEBUG 0x4
#define DIST_KERNEL_ALL0xF
/* Canned distribution sets */
Index: menus.c
===
--- menus.c (revision 240968)
+++ menus.c (working copy)
@@ -1032,6 +1032,8 @@ DMenu MenuKernelDistributions = {
{ " SMP","GENERIC symmetric multiprocessor kernel
configuration",
dmenuFlagCheck, dmenuSetFlag, NULL, &KernelDists, '[', 'X', ']',
DIST_KERNEL_SMP },
#endif
+ { " DEBUG", "DEBUG kernel configuration",
+ dmenuFlagCheck, dmenuSetFlag, NULL, &KernelDists, '[', 'X', ']',
DIST_KERNEL_DEBUG },
{ NULL } },
};
>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/172096: sysinstall does not support new DEBUG kernel distribution in 8.x
Synopsis: sysinstall does not support new DEBUG kernel distribution in 8.x Responsible-Changed-From-To: freebsd-bugs->dteske Responsible-Changed-By: dteske Responsible-Changed-When: Wed Sep 26 20:07:06 UTC 2012 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=172096 ___ 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/171815: commit references a PR
The following reply was made to PR bin/171815; it has been noted by GNATS. From: dfil...@freebsd.org (dfilter service) To: bug-follo...@freebsd.org Cc: Subject: Re: bin/171815: commit references a PR Date: Wed, 26 Sep 2012 20:47:54 + (UTC) Author: jilles Date: Wed Sep 26 20:47:39 2012 New Revision: 240974 URL: http://svn.freebsd.org/changeset/base/240974 Log: atrun: Do not assume that MAXLOGNAME <= 100. The reserved space for fmt was exactly sufficient for a two-digit value of MAXLOGNAME - 1. PR: bin/171815 Submitted by:Jeremy Huddleston Sequoia MFC after: 1 week Modified: head/libexec/atrun/atrun.c Modified: head/libexec/atrun/atrun.c == --- head/libexec/atrun/atrun.c Wed Sep 26 20:16:15 2012(r240973) +++ head/libexec/atrun/atrun.c Wed Sep 26 20:47:39 2012(r240974) @@ -123,7 +123,7 @@ run_file(const char *filename, uid_t uid pid_t pid; int fd_out, fd_in; int queue; -char mailbuf[MAXLOGNAME], fmt[49]; +char mailbuf[MAXLOGNAME], fmt[64]; char *mailname = NULL; FILE *stream; int send_mail = 0; ___ 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/171815: run_file in atrun does not allocate enough space for fmt
Synopsis: run_file in atrun does not allocate enough space for fmt State-Changed-From-To: open->patched State-Changed-By: jilles State-Changed-When: Wed Sep 26 20:50:38 UTC 2012 State-Changed-Why: Committed, thanks! Responsible-Changed-From-To: freebsd-bugs->jilles Responsible-Changed-By: jilles Responsible-Changed-When: Wed Sep 26 20:50:38 UTC 2012 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=171815 ___ 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/139271: commit references a PR
The following reply was made to PR kern/139271; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/139271: commit references a PR
Date: Thu, 27 Sep 2012 04:29:12 + (UTC)
Author: sobomax
Date: Thu Sep 27 04:28:55 2012
New Revision: 240981
URL: http://svn.freebsd.org/changeset/base/240981
Log:
Add 32-bit ABI compat shims. Those are necessary for i386 binary-only
tools like sysutils/hpacucli (HP P4xx RAID controller management
suite) working on amd64 systems.
PR: 139271
Submitted by:Kazumi MORINAGA, Eugene Grosbein
MFC after: 1 week
Modified:
head/sys/dev/pci/pci_user.c
Modified: head/sys/dev/pci/pci_user.c
==
--- head/sys/dev/pci/pci_user.cThu Sep 27 04:06:20 2012
(r240980)
+++ head/sys/dev/pci/pci_user.cThu Sep 27 04:28:55 2012
(r240981)
@@ -225,6 +225,49 @@ struct pci_io_old {
u_int32_t pi_data;/* data to write or result of read */
};
+#ifdef COMPAT_FREEBSD32
+struct pci_conf_old32 {
+ struct pcisel_old pc_sel; /* bus+slot+function */
+ u_int8_tpc_hdr; /* PCI header type */
+ u_int16_t pc_subvendor; /* card vendor ID */
+ u_int16_t pc_subdevice; /* card device ID, assigned by
+ card vendor */
+ u_int16_t pc_vendor; /* chip vendor ID */
+ u_int16_t pc_device; /* chip device ID, assigned by
+ chip vendor */
+ u_int8_tpc_class; /* chip PCI class */
+ u_int8_tpc_subclass;/* chip PCI subclass */
+ u_int8_tpc_progif; /* chip PCI programming interface */
+ u_int8_tpc_revid; /* chip revision ID */
+ charpd_name[PCI_MAXNAMELEN + 1]; /* device name */
+ u_int32_t pd_unit;/* device unit number (u_long) */
+};
+
+struct pci_match_conf_old32 {
+ struct pcisel_old pc_sel; /* bus+slot+function */
+ charpd_name[PCI_MAXNAMELEN + 1]; /* device name */
+ u_int32_t pd_unit;/* Unit number (u_long) */
+ u_int16_t pc_vendor; /* PCI Vendor ID */
+ u_int16_t pc_device; /* PCI Device ID */
+ u_int8_tpc_class; /* PCI class */
+ pci_getconf_flags_old flags; /* Matching expression */
+};
+
+struct pci_conf_io32 {
+ u_int32_t pat_buf_len;/* pattern buffer length */
+ u_int32_t num_patterns; /* number of patterns */
+ u_int32_t patterns; /* pattern buffer (struct
pci_match_conf_old32 *) */
+ u_int32_t match_buf_len; /* match buffer length */
+ u_int32_t num_matches;/* number of matches returned
*/
+ u_int32_t matches;/* match buffer (struct
pci_conf_old32 *) */
+ u_int32_t offset; /* offset into device list */
+ u_int32_t generation; /* device list generation */
+ pci_getconf_status status; /* request status */
+};
+
+#definePCIOCGETCONF_OLD32 _IOWR('p', 1, struct pci_conf_io32)
+#endif
+
#define PCIOCGETCONF_OLD_IOWR('p', 1, struct pci_conf_io)
#define PCIOCREAD_OLD _IOWR('p', 2, struct pci_io_old)
#define PCIOCWRITE_OLD _IOWR('p', 3, struct pci_io_old)
@@ -295,6 +338,69 @@ pci_conf_match_old(struct pci_match_conf
return(1);
}
+static int
+pci_conf_match_old32(struct pci_match_conf_old32 *matches, int num_matches,
+struct pci_conf *match_buf)
+{
+ int i;
+
+ if ((matches == NULL) || (match_buf == NULL) || (num_matches <= 0))
+ return(1);
+
+ for (i = 0; i < num_matches; i++) {
+ if (match_buf->pc_sel.pc_domain != 0)
+ continue;
+
+ /*
+* I'm not sure why someone would do this...but...
+*/
+ if (matches[i].flags == PCI_GETCONF_NO_MATCH_OLD)
+ continue;
+
+ /*
+* Look at each of the match flags. If it's set, do the
+* comparison. If the comparison fails, we don't have a
+* match, go on to the next item if there is one.
+*/
+ if (((matches[i].flags & PCI_GETCONF_MATCH_BUS_OLD) != 0)
+&& (match_buf->pc_sel.pc_bus != matches[i].pc_sel.pc_bus))
+ continue;
+
+ if (((matches[i].flags & PCI_GETCONF_MATCH_DEV_OLD) != 0)
+&& (match_buf->pc_sel.pc_
Re: kern/139271: [pci] [patch] sysutils/hpacucli does not work on the amd64 kernel
Synopsis: [pci] [patch] sysutils/hpacucli does not work on the amd64 kernel State-Changed-From-To: open->closed State-Changed-By: sobomax State-Changed-When: Thu Sep 27 04:31:35 UTC 2012 State-Changed-Why: Patch has been committed into the CURRENT. I'll MFC it into 9-stable and 8-stable in 1 week. Thank you for submission! http://www.freebsd.org/cgi/query-pr.cgi?pr=139271 ___ 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"
