Re: ichsmb - correct locking strategy?
On Fri, Feb 18, 2011 at 4:09 PM, Hans Petter Selasky hsela...@c2i.net wrote: On Friday 18 February 2011 15:10:47 Svatopluk Kraus wrote: Hi, I try to figure out locking strategy in FreeBSD and found 'ichsmb' device. There is a mutex which protects smb bus (ichsmb device). For example in ichsmb_readw() in sys/dev/ichsmb/ichsmb.c, the mutex is locked and a command is written to bus, then unbounded (but with timeout) sleep is done (mutex is unlocked during sleep). After sleep a word is read from bus and the mutex is unlocked. 1. If an use of the device IS NOT serialized by layers around then more calls to this function (or others) can be started or even done before the first one is finished. The mutex don't protect sms bus. 2. If an use of the device IS serialized by layers around then the mutex is useless. Moreover, I don't mension interrupt routine which uses the mutex and smb bus too. Am I right? Or did I miss something? man sx ? struct sx ? --HPS Thanks for your reply. It seems that everybody knows that ichsmb driver is not in good shape but nobody cares for ... Svata ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: machdep.hlt_cpus not safe with ULE?
on 19/02/2011 14:36 Steven Hartland said the following: I'm trying to debug a possibly failing CPU, so I thought it would be easy just disable the cores using machdep.hlt_cpus and see if we see the panic's we've been seeing. The problem is it seems ULE doesnt properly support machdep.hlt_cpus and still schedules processes onto the halted cpus which obviously causes problems. Can anyone confirm this behaviour? Yes, your observations are correct. Please also see: http://www.freebsd.org/cgi/query-pr.cgi?pr=145385 Should machdep.hlt_cpus and I assume the logical counterpart never be used with ULE? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Can vm_mmap()/vm_map_remove() be called with giant held? (linuxolator dvb patches)
On Sat, Feb 19, 2011 at 07:57:44PM +0200, Kostik Belousov wrote:
On Fri, Feb 18, 2011 at 09:55:42PM +0100, Juergen Lock wrote:
I have finally got back to this and did the style and vm_map_remove()
return value handling fixes, updated the patches in-place:
http://people.freebsd.org/~nox/dvb/linux-dvb.patch
(for head)
http://people.freebsd.org/~nox/dvb/linux-dvb-8.patch
(for 8.)
On Sun, Jan 30, 2011 at 12:54:48AM +0100, Juergen Lock wrote:
On Sat, Jan 29, 2011 at 10:51:05PM +0200, Kostik Belousov wrote:
On Sat, Jan 29, 2011 at 09:10:00PM +0100, Juergen Lock wrote:
Hi!
I was kinda hoping to be able to post a correct patch in public but
getting an answer to ${Subject} seems to be more difficult than I
thought... :) So, does anyone here know? copyout_map() and
You do not need Giant locked for vm_map* functions.
The question was more do I need to drop it first before calling them...
copyout_unmap() are copied from ksyms_map() from sys/dev/ksyms/ksyms.c
- should there maybe be global versions instead of two static copies
each, and what would be good names? And giant is taken by
linux_ioctl()
Would you make a patch for this ?
Heh if you want me to... Where should they go and are my name choices
ok?
I haven't done this yet so people can keep patching linux.ko in-place
without having to build a new kernel too...
Separate build of linux.ko is not quite supported action. I would greatly
prefer to have the move of these two functions before the rest of the
patch comes in. Together with conversion of other users.
I propose to put it into vm/vm_glue.c.
Ok, new patches are here:
http://people.freebsd.org/~nox/dvb/linux-dvb-2nd.patch
(for head, also copied below)
http://people.freebsd.org/~nox/dvb/linux-dvb-2nd-8.patch
(for 8.)
in the same source file before calling the parts I added. So here
comes the patch, it is to add support for dvb ioctls to the
linuxolator
as discussed on -emulation earlier in this thread:
http://lists.freebsd.org/pipermail/freebsd-multimedia/2011-January/011575.html
(patch also at:
http://people.freebsd.org/~nox/dvb/linux-dvb.patch
and a version for 8, which is what I tested with w_scan on dvb-s2
and dvb-t, and Andrew Gallatin also tested it with SageTV:
http://people.freebsd.org/~nox/dvb/linux-dvb-8.patch
)
+ /*
+ * Map somewhere after heap in process memory.
+ */
+ PROC_LOCK(td-td_proc);
+ *addr = round_page((vm_offset_t)vms-vm_daddr +
+ lim_max(td-td_proc, RLIMIT_DATA));
+ PROC_UNLOCK(td-td_proc);
Are you sure that this is needed ? Why not leave the address selection
to the VM ?
I don't know, maybe sys/dev/ksyms/ksyms.c has a reason?
How would I leave the address selection to the VM? Just trying
to initialize *addr to (vm_offset_t)NULL there caused the patch to
stop working.
I believe you should do
*addr = 0;
vm_mmap(map, addr);
vm_mmap() needs more args, but other than that thats basically what I
tested, and it didn't work.
Thanx, :)
Juergen
And here comes the patch for head:
Index: src/sys/vm/vm_extern.h
===
RCS file: /home/scvs/src/sys/vm/vm_extern.h,v
retrieving revision 1.99
diff -u -p -r1.99 vm_extern.h
--- src/sys/vm/vm_extern.h 27 Dec 2010 07:12:22 - 1.99
+++ src/sys/vm/vm_extern.h 20 Feb 2011 17:15:42 -
@@ -83,16 +79,16 @@ void vmspace_exitfree(struct proc *);
void vnode_pager_setsize(struct vnode *, vm_ooffset_t);
int vslock(void *, size_t);
void vsunlock(void *, size_t);
void vm_object_print(/* db_expr_t */ long, boolean_t, /* db_expr_t */ long,
char *);
int vm_fault_quick(caddr_t v, int prot);
struct sf_buf *vm_imgact_map_page(vm_object_t object, vm_ooffset_t offset);
void vm_imgact_unmap_page(struct sf_buf *sf);
void vm_thread_dispose(struct thread *td);
int vm_thread_new(struct thread *td, int pages);
void vm_thread_swapin(struct thread *td);
void vm_thread_swapout(struct thread *td);
+int copyout_map(struct thread *td, vm_offset_t *addr, size_t sz);
+int copyout_unmap(struct thread *td, vm_offset_t addr, size_t sz);
#endif /* _KERNEL */
#endif /* !_VM_EXTERN_H_ */
Index: src/sys/vm/vm_glue.c
===
RCS file: /home/scvs/src/sys/vm/vm_glue.c,v
retrieving revision 1.248
diff -u -p -r1.248 vm_glue.c
--- src/sys/vm/vm_glue.c9 Jan 2011 12:50:44 - 1.248
+++ src/sys/vm/vm_glue.c20 Feb 2011 17:23:48 -
@@ -81,6 +81,7 @@ __FBSDID($FreeBSD: src/sys/vm/vm_glue.c
#include sys/kernel.h
#include sys/ktr.h
#include
FreeBSD ABI?
Where is it documented? Are there differences with the linux ABI? Particularly I am interested in stack alignment requirement. For example i386 Solaris, Linux and MacOS have 16 bit stack alignment for procedure calls. This is reflected in LLVM sources: if (isTargetDarwin() || isTargetLinux() || isTargetSolaris() || Is64Bit) stackAlignment = 16; But FreeBSD is excluded there. Is this a bug in LLVM which magically doesn't cause crashes or this is correct and FreeBSD doesn't have 16 bit alignment? Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: machdep.hlt_cpus not safe with ULE?
On Mon, Feb 21, 2011 at 8:29 AM, Andriy Gapon a...@freebsd.org wrote: on 19/02/2011 14:36 Steven Hartland said the following: I'm trying to debug a possibly failing CPU, so I thought it would be easy just disable the cores using machdep.hlt_cpus and see if we see the panic's we've been seeing. The problem is it seems ULE doesnt properly support machdep.hlt_cpus and still schedules processes onto the halted cpus which obviously causes problems. Can anyone confirm this behaviour? Yes, your observations are correct. Please also see: http://www.freebsd.org/cgi/query-pr.cgi?pr=145385 Should machdep.hlt_cpus and I assume the logical counterpart never be used with ULE? As a followup to this and based on discussions with other folks, the fact that it's using hlt to halt CPUs without rescheduling tasks / masking interrupts, etc is not good. So none of the *hlt* sysctls are really doing the right thing on x86. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: machdep.hlt_cpus not safe with ULE?
- Original Message - From: Garrett Cooper gcoo...@freebsd.org As a followup to this and based on discussions with other folks, the fact that it's using hlt to halt CPUs without rescheduling tasks / masking interrupts, etc is not good. So none of the *hlt* sysctls are really doing the right thing on x86. Time to disable them until they are fixed properly then I would suggest? Regards Steve 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD ABI?
On Mon, Feb 21, 2011 at 10:36:39AM -0800, Yuri wrote: Where is it documented? Are there differences with the linux ABI? Particularly I am interested in stack alignment requirement. For example i386 Solaris, Linux and MacOS have 16 bit stack alignment for procedure calls. This is reflected in LLVM sources: if (isTargetDarwin() || isTargetLinux() || isTargetSolaris() || Is64Bit) stackAlignment = 16; But FreeBSD is excluded there. Is this a bug in LLVM which magically doesn't cause crashes or this is correct and FreeBSD doesn't have 16 bit alignment? the alignment is specified in bytes but yes, I wonder too, what is the stack alignment on freebsd on amd64/i386? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: machdep.hlt_cpus not safe with ULE?
On Mon, Feb 21, 2011 at 12:30 PM, Steven Hartland kill...@multiplay.co.uk wrote: - Original Message - From: Garrett Cooper gcoo...@freebsd.org As a followup to this and based on discussions with other folks, the fact that it's using hlt to halt CPUs without rescheduling tasks / masking interrupts, etc is not good. So none of the *hlt* sysctls are really doing the right thing on x86. Time to disable them until they are fixed properly then I would suggest? Andriy's patch attached to the PR above does the right thing when first bringing up the system, but it's still broken with the sysctl case, so I would actually vote to disable the sysctls for now and commit his patch separately as it's better than the existing code is in that area. Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD ABI?
Where is it documented? Are there differences with the linux ABI? Particularly I am interested in stack alignment requirement. For example i386 Solaris, Linux and MacOS have 16 bit stack alignment for procedure calls. This is reflected in LLVM sources: if (isTargetDarwin() || isTargetLinux() || isTargetSolaris() || Is64Bit) stackAlignment = 16; But FreeBSD is excluded there. Is this a bug in LLVM which magically doesn't cause crashes or this is correct and FreeBSD doesn't have 16 bit alignment? the alignment is specified in bytes but yes, I wonder too, what is the stack alignment on freebsd on amd64/i386? Isn't it supposed to [1] conform to: http://www.sco.com/developers/devspecs/abi386-4.pdf http://www.x86-64.org/documentation/abi.pdf ? [1] See, for example: http://lists.freebsd.org/pipermail/freebsd-hackers/2011-January/034045.html http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/csu/i386-elf/crt1_s.S http://lists.freebsd.org/pipermail/svn-src-head/2010-December/023065.html ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD ABI?
On 02/21/2011 14:47, b. f. wrote: Isn't it supposed to [1] conform to: http://www.sco.com/developers/devspecs/abi386-4.pdf http://www.x86-64.org/documentation/abi.pdf ? [1] See, for example: http://lists.freebsd.org/pipermail/freebsd-hackers/2011-January/034045.html http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/csu/i386-elf/crt1_s.S http://lists.freebsd.org/pipermail/svn-src-head/2010-December/023065.html Solaris-i386 ABI is also supposed to conform to abi386-4.pdf. In section 3-10 it says: The stack is word aligned. Although the architecture does not require any alignment of the stack, software convention and the operating system requires that the stack be aligned on a word boundary. But I know for the fact that Solaris-i386 uses 16 byte alignment. At least that's what gcc-4.5.2 thinks when on Solaris. Still not sure about FreeBSD-i386. Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD ABI?
On Mon, Feb 21, 2011 at 03:16:55PM -0800, Yuri wrote: But I know for the fact that Solaris-i386 uses 16 byte alignment. At least that's what gcc-4.5.2 thinks when on Solaris. That's a major difference. The Linux people decided a while ago that stack alignment should be 16 Byte. GCC effectively forces that down everyone's throat because until at least GCC 4.2 or 4.3, it can't correctly realign the stack and just fails miserable. I would be surprised if it was a conscious decision for the Solaris either. The main exception here is Mac OSX, since it defined the x86 ABI a lot latter and doesn't claim to be SYSV compatible. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD ABI?
On 02/21/2011 15:38, Joerg Sonnenberger wrote: That's a major difference. The Linux people decided a while ago that stack alignment should be 16 Byte. GCC effectively forces that down everyone's throat because until at least GCC 4.2 or 4.3, it can't correctly realign the stack and just fails miserable. I would be surprised if it was a conscious decision for the Solaris either. I filed gcc PR asking gcc to revert their behavior back to prescribed by documentation: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47842 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD ABI?
On 02/21/2011 15:38, Joerg Sonnenberger wrote: That's a major difference. The Linux people decided a while ago that stack alignment should be 16 Byte. GCC effectively forces that down everyone's throat because until at least GCC 4.2 or 4.3, it can't correctly realign the stack and just fails miserable. I would be surprised if it was a conscious decision for the Solaris either. On the other hand, 16 byte alignment allows for some extra optimizations. For example many SIMD instructions like movdqa can only be used on 16 byte aligned values. That's why linux probably decided to change this. Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD ABI?
I filed gcc PR asking gcc to revert their behavior back to prescribed by documentation: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47842 Heh, good luck!: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Problem with etc/periodic/daily/310.accounting
I was looking over etc/periodic/daily/310.accounting on a system that is very tight on space in /var, and I think that at minimum there is a race, and at best there is a pretty serious inefficiency. Right now after rotating the old logs the script does this: cp -pf acct acct.0 || rc=3 sa -s $daily_accounting_flags || rc=3 case $daily_accounting_compress in [Yy][Ee][Ss]) gzip -f acct.0 || rc=3;; esac To start with, the cp is a problem on a space-constrained system especially when the log is very large. However I think that doing it this way also introduces a race where events that are logged between the cp and the sa run are not backed up in acct.0. ITSM that the proper procedure is: mv acct acct.0 || rc=3 case $daily_accounting_compress in [Yy][Ee][Ss]) gzip --keep -f acct.0 || rc=3;; esac sa -s $daily_accounting_flags acct.0 unlink acct.0 || rc=3 Can anyone see why that would be wrong? If there is no objection, I'll be committing the attached patch. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ Index: 310.accounting === --- 310.accounting (revision 218864) +++ 310.accounting (working copy) @@ -41,13 +41,15 @@ m=$n n=$(($n - 1)) done - cp -pf acct acct.0 || rc=3 - sa -s $daily_accounting_flags || rc=3 + mv acct acct.0 || rc=3 + case $daily_accounting_compress in [Yy][Ee][Ss]) - gzip -f acct.0 || rc=3;; + gzip --keep -f acct.0 || rc=3;; esac + + sa -s $daily_accounting_flags acct.0 unlink acct.0 || rc=3 fi;; *) rc=0;; ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
buildkernel error
Hi all, I updated my kernel source code and try to make a new kernel using make buildkernel command. But I got an error as follow: : hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=make sh /usr/src/sys/conf/newvers.sh GENERIC cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror vers.c linking kernel.debug ld:/usr/src/sys/conf/ldscript.i386:66: syntax error *** Error code 1 Stop in /usr/obj/usr/src/sys/MYKERNEL. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. gnehzuil-freebsd# -- I run a freebsd OS in virtualbox. Best regards, lz ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
