[CFR] ucred.cr_gid
Could someone please take a look at it before I commit this? - Forwarded message from Ruslan Ermilov [EMAIL PROTECTED] - Date: Fri, 22 Jun 2001 18:05:09 +0300 From: Ruslan Ermilov [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: ucred.cr_gid Message-ID: [EMAIL PROTECTED] Mail-Followup-To: [EMAIL PROTECTED], [EMAIL PROTECTED] Hi! The attached patch replaces ucred.cr_groups[0] with ucred.cr_gid. This is mostly needed for POSIX alignment. setegid(2) etc. should not change supplementary groups set. Also, type of grp.h's group.gr_gid changed to a more natural gid_t (also as in POSIX). getgrouplist(3)'s and initgroups(3)'s prototypes fixed. getgrouplist(3) has been also fixed to not duplicate the primary group, and always return number of suplementary groups, even if ngroups is zero (similar to sysctl(3)). Assorted changes: cmsgcred.cmcred_egidNew kproc_info.ki_gid New portal_cred.pcr_gid New xucred.cr_gid New I'm not sure what to do with xucred. Also, I'm not sure about KINFO_PROC_SIZE on ia64 and PowerPC. Please review. See also ChangeLog. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age - End forwarded message - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GNU ld(1) dumps core
On 25 Jun, An: [EMAIL PROTECTED] wrote: It seems that there is a bug in the GNU ld(1) in -CURRENT. Currently it can't link SDL library from ports/devel/sdl12 port (confirmed by bento). When I'm replacing /usr/libexec/elf/ld with the corresponding file from my 4.3-STABLE system the problem disappears. Please check what's wrong or pass this report to the toolchain developers. Attached please find relevant log with backtrace. It seems to be a problem with nasm. I've the same problem with lame (3.89alpha), same backtrace. Oops. I wanted to say: Every software which has a problem with ld dumping core uses nasm (so far). The core dump is a bug in ld, but I didn't know if the condition which triggers the core dump is a problem with nasm, the input of nasm, or a bug in ld. Bye, Alexander. -- It is easier to fix Unix than to live with NT. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GNU ld(1) dumps core
On Tue, Jun 26, 2001 at 01:15:17PM +0200, Alexander Leidinger wrote: Oops. I wanted to say: Every software which has a problem with ld dumping core uses nasm (so far). The core dump is a bug in ld, but I didn't know if the condition which triggers the core dump is a problem with nasm, the input of nasm, or a bug in ld. If someone could provide me with the minal input to nasm which then fed to `ld' dumps core, it would really speed up a fix. :-) -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [CFR] ucred.cr_gid
On Tue, 26 Jun 2001, Ruslan Ermilov wrote: Could someone please take a look at it before I commit this? I won't get a chance to properly review this until I'm at USENIX tomorrow. If you're willing to hold off for about a week, I'd be happy to give it a fairly detailed review: I had some thoughts of doing this when I originally merged ucred and pcred a few weeks ago, but decided to hold off. I'm generally fairly positive about this change, but would be interested in hearing Bruce's thoughts on any compatibility issues, in particular, with respects to the behavior of userland processes with expectations about the old behavior. Obviously, this is a change that is very sensitive to subtle semantic changes on calls--on the other hand, I think moving towards making the supplementary groups being independent from the effect gid is a good goal, as it simplifies our credential code, and improves compatibility. Date: Fri, 22 Jun 2001 18:05:09 +0300 From: Ruslan Ermilov [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: ucred.cr_gid Message-ID: [EMAIL PROTECTED] Mail-Followup-To: [EMAIL PROTECTED], [EMAIL PROTECTED] Hi! The attached patch replaces ucred.cr_groups[0] with ucred.cr_gid. This is mostly needed for POSIX alignment. setegid(2) etc. should not change supplementary groups set. Also, type of grp.h's group.gr_gid changed to a more natural gid_t (also as in POSIX). Sounds good, I think this change was bandied about once before and perhaps simply didn't get committed. getgrouplist(3)'s and initgroups(3)'s prototypes fixed. getgrouplist(3) has been also fixed to not duplicate the primary group, and always return number of suplementary groups, even if ngroups is zero (similar to sysctl(3)). Having not looked at the patch yet, just need to make sure I point out the following areas that are sensitive to this type of change: linux and other ABI emulation, where semantic mapping of this sort is already performed, as well as userland applications managing groups. Assorted changes: cmsgcred.cmcred_egid New This is an ABI change that will break applications compiled for older versions of FreeBSD. Is this a change that applications can detect via some sort of sizeof/sanity check on cmsg results? kproc_info.ki_gid New portal_cred.pcr_gid New xucred.cr_gid New I'm not sure what to do with xucred. Probably reflect changes made in ucred fairly closely. I'll try to give you a detailed code review in a couple of days. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GNU ld(1) dumps core
At Tue, 26 Jun 2001 07:23:57 -0700, David O'Brien wrote: If someone could provide me with the minal input to nasm which then fed to `ld' dumps core, it would really speed up a fix. :-) I'm not sure when but this problem seems to be fixed in CVS at sources.redhat.com. I built binutils from sources a few days ago and their ld works as expected. -- FUJISHIMA Satsuki To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GNU ld(1) dumps core
Nevermind -- let's try binutils-2.11.2. :-) Thanks David! -- FUJISHIMA Satsuki To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GNU ld(1) dumps core
In article [EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
Oops. I wanted to say: Every software which has a problem with ld
dumping core uses nasm (so far). The core dump is a bug in ld, but I
didn't know if the condition which triggers the core dump is a problem
with nasm, the input of nasm, or a bug in ld.
If someone could provide me with the minal input to nasm which then fed
to `ld' dumps core, it would really speed up a fix. :-)
Not only nasm, but also gas has same problem. In case of
ports/audio/gogo and ports/audio/lame, nasm outputs object which
make ld dumps core. While gcc+gas outputs object which can't link
by ld. I think the problem occures when SSE instructions and
align are used. (Unfortunatry, most SSE instructions need
16Byte(=128bit) alined operands.) For example:
== bug.C ==
/* test program for SSE by kaz @ kobe1995.net
% c++ -g bug.C ./a.out
But it fails. So,
% c++ -g -S bug.C
And change loop.s to avoid bug of gcc (may be):
#APP
- movaps ($A.15),%xmm0
- movaps ($B.16),%xmm1
+ movaps A.15,%xmm0
+ movaps B.16,%xmm1
#NO_APP
% c++ loop.s ./a.out
*/
#include stdio.h
#include sys/time.h
#include unistd.h
#include stdlib.h
#include limits.h
main(){
static float __attribute__((aligned(16)))
A[4]={1.,1.,1.,1.},
B[4]={0.,1.,2.,3.},
C[4];
int i;
printf(float A=();
for(i=0;i4;i++)printf(%f,,A[i]);
printf(\b)\n);
printf(float B=();
for(i=0;i4;i++)printf(%f,,B[i]);
printf(\b)\n);
asm(movaps (%0),%%xmm0//SSE
:
:g(A));
asm(movaps (%0),%%xmm1//SSE
:
:g(B));
asm(addps %xmm1,%xmm0); //SSE
// asm(mulps %xmm1,%xmm0); //SSE
asm(movaps %%xmm0,%0:=g(C));//SSE
printf(float C=();
for(i=0;i4;i++)printf(%f,,C[i]);
printf(\b)\n);
}
--
mailto:[EMAIL PROTECTED] NAKAMURA Kazushi@KOBE
http://kobe1995.net/~kaz/index-e.html
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: GNU ld(1) dumps core
On Wed, Jun 27, 2001 at 02:16:48AM +0900, NAKAMURA Kazushi wrote: Not only nasm, but also gas has same problem. In case of ports/audio/gogo and ports/audio/lame, nasm outputs object which make ld dumps core. While gcc+gas outputs object which can't link by ld. I think the problem occures when SSE instructions and align are used. (Unfortunatry, most SSE instructions need 16Byte(=128bit) alined operands.) For example: I just committed Binutils 2.11.2. Please let me know if this helps or not. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lock order reversal
matusita lock order reversal matusita 1st 0xc5d2043c process lock @ ../../vm/vm_glue.c:487 matusita 2nd 0xc05a9ec0 lockmgr interlock @ ../../kern/kern_lock.c:239 I've caught tracelog of this reversal, with debug.witness_ddb=1. Here's console log: lock order reversal 1st 0xc5e3cfdc process lock @ ../../vm/vm_glue.c:487 2nd 0xc05a9f80 lockmgr interlock @ ../../kern/kern_lock.c:239 Debugger(witness_lock) Stopped at Debugger+0x44: pushl %ebx db trace Debugger(c02bd5ae) at Debugger+0x44 witness_lock(c05a9f80,8,c02b8d54,ef) at witness_lock+0x90d lockmgr(c5dbe7d0,12,0,c5420640) at lockmgr+0x97 swapout_procs(1,c02686e0,c5420640,0,c582df94) at swapout_procs+0xc46 vm_daemon(0,c582dfa8) at vm_daemon+0x128 fork_exit(c02686e0,0,c582dfa8) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 db I don't know whether it is reproducible, but it's early morning (6 AM), mkisofs(1) is just running to make an ISO image for me (for backup). -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lock order reversal
On 27-Jun-01 Makoto MATSUSHITA wrote: matusita lock order reversal matusita 1st 0xc5d2043c process lock @ ../../vm/vm_glue.c:487 matusita 2nd 0xc05a9ec0 lockmgr interlock @ ../../kern/kern_lock.c:239 I've caught tracelog of this reversal, with debug.witness_ddb=1. Here's console log: lock order reversal 1st 0xc5e3cfdc process lock @ ../../vm/vm_glue.c:487 2nd 0xc05a9f80 lockmgr interlock @ ../../kern/kern_lock.c:239 Debugger(witness_lock) Stopped at Debugger+0x44: pushl %ebx db trace Debugger(c02bd5ae) at Debugger+0x44 witness_lock(c05a9f80,8,c02b8d54,ef) at witness_lock+0x90d lockmgr(c5dbe7d0,12,0,c5420640) at lockmgr+0x97 swapout_procs(1,c02686e0,c5420640,0,c582df94) at swapout_procs+0xc46 vm_daemon(0,c582dfa8) at vm_daemon+0x128 fork_exit(c02686e0,0,c582dfa8) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 db I don't know whether it is reproducible, but it's early morning (6 AM), mkisofs(1) is just running to make an ISO image for me (for backup). Ok, this one is due to braindeadedness in lockmgr(), and will just have to stay the way it is until vm map locks switch to being sx locks instead of lockmgr locks. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SCSI hangs w/SuperMicro 6010H
John Baldwin wrote: Hrmm, perhaps you are getting an interrupt storm from ahc. Ok, try this: find the ahc driver's interrupt handler, and add a printf. Then see if the printf fires while the machine is hung. Ok, I put a printf in ahc_handle_seqint() and ahc_handle_scsiint(). That won't catch all interrupts. Most notably, you won't know if commands are completing. Command completions are much more prevalent than sequencer or scsi interrupts. My current (freshly cvsupped sources) kernel with the printf()s in it is pretty consistent in it's behavior: with SMP it hangs soon after the 15 second SCSI delay and keystrokes will not cause it to continue to boot. The order that they print out on the screen is this: message Waiting 15 seconds for SCSI devices to settle (approximately 15 second delay) 26 times scsiint called with intstat = 0x4, status0 = 0, status = 0x88 (SELTO BUSFREE?) So 26 of the 30 possible target ID positions on the controller are empty. 2 times seqint called with instat = 0x71 (BAD_STATUS?) Two commands returned status other than 0 - most likely check condition. 36 times seqint called with intstat = 0x61 (HOST_MSG_LOOP?) We negotiated transfer settings with some devices. These all seem quite normal. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SCSI hangs w/SuperMicro 6010H
Justin T. Gibbs wrote: John Baldwin wrote: Hrmm, perhaps you are getting an interrupt storm from ahc. Ok, try this: find the ahc driver's interrupt handler, and add a printf. Then see if the printf fires while the machine is hung. Ok, I put a printf in ahc_handle_seqint() and ahc_handle_scsiint(). That won't catch all interrupts. Most notably, you won't know if commands are completing. Command completions are much more prevalent than sequencer or scsi interrupts. should I try and catch the command completions? which routine is best to do this in? btw, thanks very much for your help! dave c -- Dave Cornejo @ Dogwood Media, Fremont, California (also [EMAIL PROTECTED]) There aren't any monkeys chasing us... - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SCSI hangs w/SuperMicro 6010H
That won't catch all interrupts. Most notably, you won't know if commands are completing. Command completions are much more prevalent than sequencer or scsi interrupts. should I try and catch the command completions? which routine is best to do this in? ahc_intr() in aic7xxx_inline.h gates all interrupt activity. I don't know that it will tell you why you are hung though. All that is clear is that interrupts at least work for a time. btw, thanks very much for your help! Sure. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
