Re: amd64/150023: network subsystem does not work at all
Synopsis: network subsystem does not work at all Responsible-Changed-From-To: freebsd-amd64->freebsd-bugs Responsible-Changed-By: avg Responsible-Changed-When: Fri Oct 8 09:23:39 UTC 2010 Responsible-Changed-Why: The PR doesn't describe any amd64-specific problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=150023 ___ 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: amd64/148805: [hang] FreeBSD 7.2, 8.0, and 9.0 hang during install at probing devices
Synopsis: [hang] FreeBSD 7.2, 8.0, and 9.0 hang during install at probing devices Responsible-Changed-From-To: freebsd-amd64->freebsd-bugs Responsible-Changed-By: avg Responsible-Changed-When: Fri Oct 8 09:32:10 UTC 2010 Responsible-Changed-Why: There is no indication in the report (and followups) that this is a problem specific to amd64 architecture. Seems like a sysinstall issue. http://www.freebsd.org/cgi/query-pr.cgi?pr=148805 ___ 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: amd64/148675: [panic] kernel panics - reboots
Synopsis: [panic] kernel panics - reboots Responsible-Changed-From-To: freebsd-amd64->freebsd-bugs Responsible-Changed-By: avg Responsible-Changed-When: Fri Oct 8 09:34:55 UTC 2010 Responsible-Changed-Why: This seems like a know locking problem in ATA code that is not specific to amd64 arch. The problem is typically triggered by command timeout. To reporter: please try using ahci(4) driver and ATA_CAM kernel option. http://www.freebsd.org/cgi/query-pr.cgi?pr=148675 ___ 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: amd64/147560: [boot] Booting 8.1-PRERELEASE raidz system take ages
Synopsis: [boot] Booting 8.1-PRERELEASE raidz system take ages Responsible-Changed-From-To: freebsd-amd64->freebsd-bugs Responsible-Changed-By: avg Responsible-Changed-When: Fri Oct 8 09:37:58 UTC 2010 Responsible-Changed-Why: This is a generic zfs boot problem resulting from how the code finds disks for zfs pools. Not sure if we can do any better here. http://www.freebsd.org/cgi/query-pr.cgi?pr=147560 ___ 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/147560: [zfs] [boot] Booting 8.1-PRERELEASE raidz system take ages
Old Synopsis: [boot] Booting 8.1-PRERELEASE raidz system take ages New Synopsis: [zfs] [boot] Booting 8.1-PRERELEASE raidz system take ages Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Fri Oct 8 10:28:51 UTC 2010 Responsible-Changed-Why: apparently ZFS-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=147560 ___ 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/151304: patch - definitions of variables tested by ASSERT_ATOMIC_LOAD_PTR
>Number: 151304
>Category: kern
>Synopsis: patch - definitions of variables tested by
>ASSERT_ATOMIC_LOAD_PTR
>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 Oct 08 12:30:01 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Svatopluk Kraus
>Release:current
>Organization:
>Environment:
coldfire port
>Description:
A macro ASSERT_ATOMIC_LOAD_PTR() hits in colfire port I work on. It is possibly
due to use of GNU GCC (4.5.1) compiler -Os option (size optimalization). The
macro is applied on four places:
sys/kern/kern_lock.c
sys/kern/kern_mutex.c
sys/kern/kern_rwlock.c
sys/kern/kern_sx.c
and tests entries in four structures:
volatile uintptr_t lk_lock -> struct lock -> sys/sys/_lockmgr.h
volatile uintptr_t mtx_lock -> struct mtx -> sys/sys/_mutex.h
volatile uintptr_t rw_lock -> struct rwlock -> sys/sys/_rwlock.h
volatile uintptr_t sx_lock -> struct sx -> sys/sys/_sx.h
>How-To-Repeat:
>Fix:
I patch the entries definitions in structures by align attribute, I believe it
is better than to do nothing. Moreover, it solved my problem.
Patch attached with submission follows:
Index: sys/sys/_rwlock.h
===
--- sys/sys/_rwlock.h (revision 213567)
+++ sys/sys/_rwlock.h (working copy)
@@ -37,7 +37,7 @@
*/
struct rwlock {
struct lock_object lock_object;
- volatile uintptr_t rw_lock;
+ volatile uintptr_t rw_lock __aligned(4);
};
#endif /* !_SYS__RWLOCK_H_ */
Index: sys/sys/_sx.h
===
--- sys/sys/_sx.h (revision 213567)
+++ sys/sys/_sx.h (working copy)
@@ -36,7 +36,7 @@
*/
struct sx {
struct lock_object lock_object;
- volatile uintptr_t sx_lock;
+ volatile uintptr_t sx_lock __aligned(4);
};
#endif /* !_SYS__SX_H_ */
Index: sys/sys/_lockmgr.h
===
--- sys/sys/_lockmgr.h (revision 213567)
+++ sys/sys/_lockmgr.h (working copy)
@@ -37,7 +37,7 @@
struct lock {
struct lock_object lock_object;
- volatile uintptr_t lk_lock;
+ volatile uintptr_t lk_lock __aligned(4);
u_int lk_exslpfail;
int lk_timo;
int lk_pri;
Index: sys/sys/_mutex.h
===
--- sys/sys/_mutex.h(revision 213567)
+++ sys/sys/_mutex.h(working copy)
@@ -35,8 +35,8 @@
* Sleep/spin mutex.
*/
struct mtx {
- struct lock_object lock_object;/* Common lock properties. */
- volatile uintptr_t mtx_lock; /* Owner and flags. */
+ struct lock_object lock_object;/* Common lock
properties. */
+ volatile uintptr_t mtx_lock __aligned(4); /* Owner and flags. */
};
#endif /* !_SYS__MUTEX_H_ */
>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"
kern/151305: [patch] - CTASSERT(sizeof(struct jmvrec) == JREC_SIZE)
>Number: 151305 >Category: kern >Synopsis: [patch] - CTASSERT(sizeof(struct jmvrec) == JREC_SIZE) >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 Oct 08 13:20:03 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Svatopluk Kraus >Release:current >Organization: >Environment: coldfire port >Description: A macro CTASSERT() hits in colfire port I work on. It is possibly due to use of GNU GCC compiler -Os option (size optimalization). It hits on struct jmvrec in sys/ufs/ffs/fs.h. >How-To-Repeat: >Fix: I arranged the struct definition (a size of unused field). Patch attached with submission follows: Index: sys/ufs/ffs/fs.h === --- sys/ufs/ffs/fs.h(revision 213567) +++ sys/ufs/ffs/fs.h(working copy) @@ -696,7 +696,7 @@ uint32_tjm_op; ino_t jm_ino; ino_t jm_parent; - uint16_tjm_unused; + uint32_tjm_unused; off_t jm_oldoff; off_t jm_newoff; }; >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/151321: mount_nfs won't recognize readahead
>Number: 151321 >Category: bin >Synopsis: mount_nfs won't recognize readahead >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Oct 08 19:10:04 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Simon Walton >Release:8.1 >Organization: >Environment: FreeBSD mongo 8.1-RELEASE FreeBSD 8.1-RELEASE #1: Thu Oct 7 18:25:36 PDT 2010 >Description: Mount_nfs won't recognize any form of the readahead parameter: mongo# mount_nfs -a 2 m-6:/mnt/dodo /cdrom -a deprecated, use -o readhead= mount_nfs: /cdrom, mount option is unknown: Invalid argument mongo# mount_nfs -o readahead=2 m-6:/mnt/dodo /cdrom mount_nfs: /cdrom, mount option is unknown: Invalid argument mongo# mount_nfs -o readhead=2 m-6:/mnt/dodo /cdrom mount_nfs: /cdrom, mount option is unknown: Invalid argument The mount operation is unsuccessful in all cases. In previous releases this option was a significant performance increase for us. >How-To-Repeat: mount_nfs -o readahead=2 ... >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/151304: patch - definitions of variables tested by ASSERT_ATOMIC_LOAD_PTR
On Fri, 8 Oct 2010, Svatopluk Kraus wrote:
Description:
A macro ASSERT_ATOMIC_LOAD_PTR() hits in colfire port I work on. It is possibly
due to use of GNU GCC (4.5.1) compiler -Os option (size optimalization). The
macro is applied on four places:
Perhaps gcc-4.5.1 -Os is doing invalid packing of structs, or FreeBSD has
broken packing of structs using the __packed mistake and gcc-4.5.1 -Os
exposes the brokenness by exploiting __packed more. Probably the latter.
BTW, gcc-4.2.1 -Os is still completely broken on kernels. It fails to
compile some files due to problems with -Wuninitialized, and when this
is worked around it produces a kernel that is about 50% larger than one
produced by gcc-4.2.1 -O. A few years ago I thought the problem was
excessive inlining, but when I tried to fix it a few weeks ago, reducing
the inlining caused larger problems and still gave large negative
optimizations.
Fix:
I patch the entries definitions in structures by align attribute, I believe it
is better than to do nothing. Moreover, it solved my problem.
Patch attached with submission follows:
Index: sys/sys/_rwlock.h
===
--- sys/sys/_rwlock.h (revision 213567)
+++ sys/sys/_rwlock.h (working copy)
@@ -37,7 +37,7 @@
*/
struct rwlock {
struct lock_object lock_object;
- volatile uintptr_t rw_lock;
+ volatile uintptr_t rw_lock __aligned(4);
};
#endif /* !_SYS__RWLOCK_H_ */
...
This does nothing good on arches with 64-bit pointers. With gcc-4.2.1 on
amd64, it seems to do nothing -- the natural alignment of a uintptr_t on
amd64 is 8, and asking for a smaller alignment using __aligned(4) apparently
makes no difference. It takes __aligned(more_than_8) or __packed to make a
difference.
Here is an example of creating an alignment bug due using __packed and just
gcc-4.2.1 on amd64:
% #include
% #include
%
% struct foo {
% int x;
% longy __aligned(4);
% };
%
% struct bar {
% charc;
% struct foo d;
% } __packed;
%
% int z = offsetof(struct foo, y);
% int t = sizeof (struct bar);
'y' has the correct offset of 8, but `struct bar' has size 17, so the `y'
nested in it cannot possibly be aligned properly, at least if there is an
array of `struct bar' with at least 2 elements. I think this is a compiler
bug -- the explicit __aligned(4) in the nested struct should force alignment
of container structs (but only to 4 here, not the 8 that is required).
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: kern/151304: patch - definitions of variables tested by ASSERT_ATOMIC_LOAD_PTR
The following reply was made to PR kern/151304; it has been noted by GNATS.
From: Bruce Evans
To: Svatopluk Kraus
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org
Subject: Re: kern/151304: patch - definitions of variables tested by
ASSERT_ATOMIC_LOAD_PTR
Date: Sat, 9 Oct 2010 07:16:43 +1100 (EST)
On Fri, 8 Oct 2010, Svatopluk Kraus wrote:
>> Description:
> A macro ASSERT_ATOMIC_LOAD_PTR() hits in colfire port I work on. It is
> possibly due to use of GNU GCC (4.5.1) compiler -Os option (size
> optimalization). The macro is applied on four places:
Perhaps gcc-4.5.1 -Os is doing invalid packing of structs, or FreeBSD has
broken packing of structs using the __packed mistake and gcc-4.5.1 -Os
exposes the brokenness by exploiting __packed more. Probably the latter.
BTW, gcc-4.2.1 -Os is still completely broken on kernels. It fails to
compile some files due to problems with -Wuninitialized, and when this
is worked around it produces a kernel that is about 50% larger than one
produced by gcc-4.2.1 -O. A few years ago I thought the problem was
excessive inlining, but when I tried to fix it a few weeks ago, reducing
the inlining caused larger problems and still gave large negative
optimizations.
>> Fix:
> I patch the entries definitions in structures by align attribute, I believe
> it is better than to do nothing. Moreover, it solved my problem.
>
> Patch attached with submission follows:
>
> Index: sys/sys/_rwlock.h
> ===
> --- sys/sys/_rwlock.h (revision 213567)
> +++ sys/sys/_rwlock.h (working copy)
> @@ -37,7 +37,7 @@
> */
> struct rwlock {
>struct lock_object lock_object;
> - volatile uintptr_t rw_lock;
> + volatile uintptr_t rw_lock __aligned(4);
> };
>
> #endif /* !_SYS__RWLOCK_H_ */
> ...
This does nothing good on arches with 64-bit pointers. With gcc-4.2.1 on
amd64, it seems to do nothing -- the natural alignment of a uintptr_t on
amd64 is 8, and asking for a smaller alignment using __aligned(4) apparently
makes no difference. It takes __aligned(more_than_8) or __packed to make a
difference.
Here is an example of creating an alignment bug due using __packed and just
gcc-4.2.1 on amd64:
% #include
% #include
%
% struct foo {
% int x;
% longy __aligned(4);
% };
%
% struct bar {
% charc;
% struct foo d;
% } __packed;
%
% int z = offsetof(struct foo, y);
% int t = sizeof (struct bar);
'y' has the correct offset of 8, but `struct bar' has size 17, so the `y'
nested in it cannot possibly be aligned properly, at least if there is an
array of `struct bar' with at least 2 elements. I think this is a compiler
bug -- the explicit __aligned(4) in the nested struct should force alignment
of container structs (but only to 4 here, not the 8 that is required).
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"
kern/151326: nfs exports fail if netgroups contain duplicate entries
>Number: 151326 >Category: kern >Synopsis: nfs exports fail if netgroups contain duplicate entries >Confidential: no >Severity: non-critical >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Oct 08 23:30:05 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Jeff Strunk >Release:8.1-RELEASE >Organization: The University of Texas at Austin Department of Mathematics >Environment: FreeBSD thinkmate2.ma.utexas.edu 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:36:49 UTC 2010 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >Description: We are setting up a couple of file servers using ZFS to replace our old Debian file servers. We have been using netgroups to allow a group of admin machines to access the files without remapping root to nobody(no_root_squash on linux and -maproot=0 on FreeBSD). All of our machines that access the nfs servers are in the utm netgroup. We use an export line for that netgroup to restrict rw access to our nfs servers. So, our exports file in FreeBSD looks like(there are more lines, but they all look like these with the filesystem changed): /thinkmate1 -maproot=0 admin /thinkmate1 utm When mountd is started, it logs: Oct 8 16:37:21 thinkmate2 mountd[2242]: bad exports list line /thinkmate1 utm mountd -d shows the following the 2nd time a filesystem is exported: mountd: can't change attributes for /thinkmate1 When I try to mount /thinkmate1 from an admin machine, it works. Also, root is able to read and write any files. When I try to mount on a non-admin machine, the client reports that it was denied by the server. If I reverse the exports lines, all hosts in the utm netgroup can access /thinkmate1, but root on admin hosts is mapped to nobody. I discovered that some hostnames are found in both the admin and utm netgroups. When I took the admin hosts out of the utm netgroup, everything worked. This is not a problem on either Linux or Solaris. >How-To-Repeat: 1) Create the following files. /etc/netgroup(replace 4 spaces with tab): admin \ (hosta,,domain) domain \ (hosta,,domain) \ (hostb,,domain) /etc/exports: /export -maproot=0 admin /export domain 2) Restart mountd. 3) Try to nfs mount /export from hostb. >Fix: The workaround is to clean up duplicate netgroup entries. It looks like each host can only be in one netgroup. >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"
