Re: Loader reading FAT
2009/6/17 Rick C. Petty : > I read somewhere that there isn't enough space in the boot2 loader to put > such logic. You're only guaranteed 15 512-byte sectors or 7680 bytes, if > you use any UFS partition. It's pretty tight; I think you will find it > difficult to insert another file system in there, especially one as > complicated as msdos. libstand is 223 KB, so it's not as trivial as you > think. > > Theoretically it would be possible: for example, if you're willing to set > aside a separate partition you would have as much room as you want. Or if > you put it at the front of a UFS partition, you have just under 256 KB of > room since our UFS code will search for the superblock at a byte offset of > 262144, but there aren't any knobs to newfs so you'd have to hack it > together. Take a look at /usr/src/sys/boot/i386/boot2/ for starters. This is why I pointed out the NetBSD DOS bootloader stuff. In effect, you could "just" boot a FreeBSD install by teaching the NetBSD bootloader and loader(8) enough about each other to initialise loader; loader then has much more memory to play with understanding multiple filesystems and slicing/labelling methods. Boot0, boot1, boot2 wouldn't even be involved. Adrian ___ 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: How best to debug locking/scheduler problems
On Tuesday 16 June 2009 7:01:45 pm Mel Flynn wrote: > On Tuesday 16 June 2009 11:02:42 John Baldwin wrote: > > On Tuesday 16 June 2009 1:52:23 pm Mel Flynn wrote: > > > Hi John, > > > > > > On Tuesday 16 June 2009 04:19:57 John Baldwin wrote: > > > > On Monday 15 June 2009 5:53:05 pm Mel Flynn wrote: > > > > > PIDTID COMM TDNAME KSTACK > > > > > 4283 100215 kdeinit4 -mi_switch > > > > > turnstile_wait _mtx_lock_sleep uipc_peeraddr kern_getpeername > > > > > getpeername syscall Xint0x80_syscall > > > > > % ps -ww 4283 > > > > > PID TT STAT TIME COMMAND > > > > > 4283 ?? T 0:00.38 kdeinit4: kdeinit4: kio_http http > > > > > local:/tmp/ksocket-mel/klauncherxJ1635.slave-socket > > > > > local:/tmp/ksocket- mel/plasmayC1653.slave-socket (kdeinit4) > > > > > > > > > > %ls -l /tmp/ksocket-mel/ > > > > > > > > > > total 2 > > > > > -rw-rw-r-- 1 mel wheel 62 Jun 14 22:55 KSMserver__0 > > > > > srw--- 1 mel wheel 0 Jun 14 22:55 kdeinit4__0 > > > > > srwxrwxr-x 1 mel wheel 0 Jun 14 22:55 > > > > > klauncherxJ1635.slave-socket > > > > > > > > You can use kgdb and the scripts at www.freebsd.org/~jhb/gdb. Simply > > > > run 'kgdb' as root and do 'lcd /folder/with/scripts' and 'source gdb6'. > > > > You can then do 'lockchain 4283' to find who holds the lock this thread > > > > is blocked on and what state they are in. > > > > > > Looks like a deadlock: > > > > > > (kgdb) lockchain 4283 > > > thread 100215 (pid 4283, kdeinit4) blocked on lock 0xc64374a0 "unp_mtx" > > > thread 100122 (pid 1635, klauncher) blocked on lock 0xc6806348 "unp_mtx" > > > thread 100215 (pid 4283, kdeinit4) blocked on lock 0xc64374a0 "unp_mtx" > > > thread 100122 (pid 1635, klauncher) blocked on lock 0xc6806348 "unp_mtx" > > > thread 100215 (pid 4283, kdeinit4) blocked on lock 0xc64374a0 "unp_mtx" > > > thread 100122 (pid 1635, klauncher) blocked on lock 0xc6806348 "unp_mtx" > > > thread 100215 (pid 4283, kdeinit4) blocked on lock 0xc64374a0 "unp_mtx" > > > thread 100122 (pid 1635, klauncher) blocked on lock 0xc6806348 "unp_mtx" > > > thread 100215 (pid 4283, kdeinit4) blocked on lock 0xc64374a0 "unp_mtx" > > > thread 100122 (pid 1635, klauncher) blocked on lock 0xc6806348 "unp_mtx" > > > thread 100215 (pid 4283, kdeinit4) blocked on lock 0xc64374a0 "unp_mtx" > > > thread 100122 (pid 1635, klauncher) blocked on lock 0xc6806348 "unp_mtx" > > > thread 100215 (pid 4283, kdeinit4) blocked on lock 0xc64374a0 "unp_mtx" > > > thread 100122 (pid 1635, klauncher) blocked on lock 0xc6806348 "unp_mtx" > > > thread 100215 (pid 4283, kdeinit4) blocked on lock 0xc64374a0 "unp_mtx" > > > thread 100122 (pid 1635, klauncher) blocked on lock 0xc6806348 "unp_mtx" > > > thread 100215 (pid 4283, kdeinit4) blocked on lock 0xc64374a0 "unp_mtx" > > > thread 100122 (pid 1635, klauncher) blocked on lock 0xc6806348 "unp_mtx" > > > thread 100215 (pid 4283, kdeinit4) blocked on lock 0xc64374a0 "unp_mtx" > > > thread 100122 (pid 1635, klauncher) blocked on lock 0xc6806348 "unp_mtx" > > > DEADLOCK > > > > > > Looking through the scripts now to see how I can get more info on the > > > call chain and hoping I don't panic the machine ;). It is quite random to > > > reproduce. > > > > In kgdb you can simply do 'tid 100122' followed by 'bt' and 'tid 100215' > > followed by 'bt'. > > Cool, thanks for helping John. Of course it pretty much shows me what > procstat > -k shows and can't get any info on the userland part, but I can fully inspect > the locks and threads. > > Both threads are in TDS_INHIBITED state, and blocked on: > (kgdb) frame 0 > #0 sched_switch (td=0xc5971240, newtd=0xc4d39900, flags=259) > at /usr/src/sys/kern/sched_ule.c:1864 > 1864cpuid = PCPU_GET(cpuid); That doesn't really tell us anything except that it isn't running. We know it is actually blocked on a lock, and we need the full stack trace to see where the two threads were trying to acquire the locks, hence 'bt'. ' procstat -k' output would be fine, too. -- John Baldwin ___ 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: tmpfs experimental?
On Tue, 16 Jun 2009, Wojciech Puchar wrote: WP> > > In other words, is there still reason for the "highly experimental WP> > > feature" warning? WP> > WP> > Last time when I added the warning, it was because some data corruption WP> > issue that can be identified by fsx which I didn't got a chance to WP> > investigate further. I think tmpfs is Ok for some usual work but maybe WP> > not ready for production at that moment. alc@ and kib@ has made a lot WP> > of changes on it recently so perhaps we need to re-visit the problems, WP> > tmpfs would be a great feature for us. WP> WP> as an ordinary user not programmer of tmpfs i can say that: WP> WP> 1) runs fine for months in production environments, including case with over WP> 40 mountpoints (jails) WP> 2) runs really fast when memory is available. WP> 3) performance is bad in case that swapping actually is used. It reads from WP> swap with too small chunks. it's a place for improvement here. WP> WP> Its great thing as it does it properly - memory is immediately freed on WP> delete, and no caching of memory disk like with md(4). Actually, buffer cache is used, so excessive memory usage are still in place; also, on rather heavy tmpfs usage (building large ports, for example) I still can panic and/or hang the machione with exhausted maxswzone, so there definitely is a place to improve things ;) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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"
small usr.bin/find patch
hi everybody, here's just a quick hack i applied to find. i very often use the -size switch and always forget if you need to append "m" or "M" for megabyte or "k" or "K" for kilobyte. after applying the patch find accepts both. ;-) cheers. findpatch Description: Binary data ___ 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: How best to debug locking/scheduler problems
On Wednesday 17 June 2009 04:15:26 John Baldwin wrote: > On Tuesday 16 June 2009 7:01:45 pm Mel Flynn wrote: > > On Tuesday 16 June 2009 11:02:42 John Baldwin wrote: > > > On Tuesday 16 June 2009 1:52:23 pm Mel Flynn wrote: > > > > Hi John, > > > > > > > > On Tuesday 16 June 2009 04:19:57 John Baldwin wrote: > > > > > On Monday 15 June 2009 5:53:05 pm Mel Flynn wrote: > > > > > > PIDTID COMM TDNAME KSTACK > > > > > > 4283 100215 kdeinit4 -mi_switch > > > > > > turnstile_wait _mtx_lock_sleep uipc_peeraddr kern_getpeername > > > > > > getpeername syscall Xint0x80_syscall > > > > > > % ps -ww 4283 > > > > > > PID TT STAT TIME COMMAND > > > > > > 4283 ?? T 0:00.38 kdeinit4: kdeinit4: kio_http http > > > > > > local:/tmp/ksocket-mel/klauncherxJ1635.slave-socket > > > > > > local:/tmp/ksocket- mel/plasmayC1653.slave-socket (kdeinit4) > > > > > > > > > > > > %ls -l /tmp/ksocket-mel/ > > > > > > > > > > > > total 2 > > > > > > -rw-rw-r-- 1 mel wheel 62 Jun 14 22:55 KSMserver__0 > > > > > > srw--- 1 mel wheel 0 Jun 14 22:55 kdeinit4__0 > > > > > > srwxrwxr-x 1 mel wheel 0 Jun 14 22:55 > > > > > > klauncherxJ1635.slave-socket > > > > > > > > > > You can use kgdb and the scripts at www.freebsd.org/~jhb/gdb. > > > > > Simply run 'kgdb' as root and do 'lcd /folder/with/scripts' and > > > > > 'source gdb6'. You can then do 'lockchain 4283' to find who holds > > > > > the lock this thread is blocked on and what state they are in. > > > > > > > > Looks like a deadlock: > > > > > > > > (kgdb) lockchain 4283 > > > > thread 100215 (pid 4283, kdeinit4) blocked on lock 0xc64374a0 > > > > "unp_mtx" thread 100122 (pid 1635, klauncher) blocked on lock > > > > 0xc6806348 "unp_mtx" thread 100215 (pid 4283, kdeinit4) blocked on > > > > lock 0xc64374a0 "unp_mtx" thread 100122 (pid 1635, klauncher) blocked > > > > on lock 0xc6806348 "unp_mtx" thread 100215 (pid 4283, kdeinit4) > > > > blocked on lock 0xc64374a0 "unp_mtx" thread 100122 (pid 1635, > > > > klauncher) blocked on lock 0xc6806348 "unp_mtx" thread 100215 (pid > > > > 4283, kdeinit4) blocked on lock 0xc64374a0 "unp_mtx" thread 100122 > > > > (pid 1635, klauncher) blocked on lock 0xc6806348 "unp_mtx" thread > > > > 100215 (pid 4283, kdeinit4) blocked on lock 0xc64374a0 "unp_mtx" > > > > thread 100122 (pid 1635, klauncher) blocked on lock 0xc6806348 > > > > "unp_mtx" thread 100215 (pid 4283, kdeinit4) blocked on lock > > > > 0xc64374a0 "unp_mtx" thread 100122 (pid 1635, klauncher) blocked on > > > > lock 0xc6806348 "unp_mtx" thread 100215 (pid 4283, kdeinit4) blocked > > > > on lock 0xc64374a0 "unp_mtx" thread 100122 (pid 1635, klauncher) > > > > blocked on lock 0xc6806348 "unp_mtx" thread 100215 (pid 4283, > > > > kdeinit4) blocked on lock 0xc64374a0 "unp_mtx" thread 100122 (pid > > > > 1635, klauncher) blocked on lock 0xc6806348 "unp_mtx" thread 100215 > > > > (pid 4283, kdeinit4) blocked on lock 0xc64374a0 "unp_mtx" thread > > > > 100122 (pid 1635, klauncher) blocked on lock 0xc6806348 "unp_mtx" > > > > thread 100215 (pid 4283, kdeinit4) blocked on lock 0xc64374a0 > > > > "unp_mtx" thread 100122 (pid 1635, klauncher) blocked on lock > > > > 0xc6806348 "unp_mtx" DEADLOCK > > > > > > > > Looking through the scripts now to see how I can get more info on the > > > > call chain and hoping I don't panic the machine ;). It is quite > > > > random to reproduce. > > > > > > In kgdb you can simply do 'tid 100122' followed by 'bt' and 'tid > > > 100215' followed by 'bt'. > > > > Cool, thanks for helping John. Of course it pretty much shows me what > > procstat -k shows and can't get any info on the userland part, but I can > > fully inspect the locks and threads. > > > > Both threads are in TDS_INHIBITED state, and blocked on: > > (kgdb) frame 0 > > #0 sched_switch (td=0xc5971240, newtd=0xc4d39900, flags=259) > > at /usr/src/sys/kern/sched_ule.c:1864 > > 1864cpuid = PCPU_GET(cpuid); > > That doesn't really tell us anything except that it isn't running. We know > it is actually blocked on a lock, and we need the full stack trace to see > where the two threads were trying to acquire the locks, hence 'bt'. ' > procstat -k' output would be fine, too. They're blocking on each other: (kgdb) tid 100122 (kgdb) print td->td_contested.lh_first $16 = (struct turnstile *) 0xc4f8fb00 (kgdb) print td->td_lock $17 = (struct mtx * volatile) 0xc538cb00 (kgdb) tid 100215 (kgdb) print td->td_contested.lh_first $18 = (struct turnstile *) 0xc538cb00 (kgdb) print td->td_lock $19 = (struct mtx * volatile) 0xc4f8fb00 the respective bt's: (kgdb) tid 100122 #0 sched_switch (td=0xc56e8900, newtd=0xc4d39b40, flags=259) at /usr/src/sys/kern/sched_ule.c:1864 #1 0xc064bcfa in mi_switch (flags=259, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:444 #2 0xc067d30b in turnstile_wait (ts=0xc538cb00, owner=0xc5971240, queue=Variable "queue" is not available. ) at /usr/src/sys/kern/subr_turnstile.
Re: small usr.bin/find patch
Alexander Best wrote: hi everybody, here's just a quick hack i applied to find. i very often use the -size switch and always forget if you need to append "m" or "M" for megabyte or "k" or "K" for kilobyte. after applying the patch find accepts both. ;-) cheers. Are you sure this is wise? after all 125 millibytes would be 1 bit.. ( :-) ) ___ 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" ___ 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: How best to debug locking/scheduler problems
On Wednesday 17 June 2009 3:52:54 pm Mel Flynn wrote: > On Wednesday 17 June 2009 04:15:26 John Baldwin wrote: > > On Tuesday 16 June 2009 7:01:45 pm Mel Flynn wrote: > > > On Tuesday 16 June 2009 11:02:42 John Baldwin wrote: > > > > On Tuesday 16 June 2009 1:52:23 pm Mel Flynn wrote: > > > > > Hi John, > > > > > > > > > > On Tuesday 16 June 2009 04:19:57 John Baldwin wrote: > > > > > > On Monday 15 June 2009 5:53:05 pm Mel Flynn wrote: > > > > > > > PIDTID COMM TDNAME KSTACK > > > > > > > 4283 100215 kdeinit4 -mi_switch > > > > > > > turnstile_wait _mtx_lock_sleep uipc_peeraddr kern_getpeername > > > > > > > getpeername syscall Xint0x80_syscall > > > > > > > % ps -ww 4283 > > > > > > > PID TT STAT TIME COMMAND > > > > > > > 4283 ?? T 0:00.38 kdeinit4: kdeinit4: kio_http http > > > > > > > local:/tmp/ksocket-mel/klauncherxJ1635.slave-socket > > > > > > > local:/tmp/ksocket- mel/plasmayC1653.slave-socket (kdeinit4) > > > > > > > > > > > > > > %ls -l /tmp/ksocket-mel/ > > > > > > > > > > > > > > total 2 > > > > > > > -rw-rw-r-- 1 mel wheel 62 Jun 14 22:55 KSMserver__0 > > > > > > > srw--- 1 mel wheel 0 Jun 14 22:55 kdeinit4__0 > > > > > > > srwxrwxr-x 1 mel wheel 0 Jun 14 22:55 > > > > > > > klauncherxJ1635.slave-socket > > > > > > > > > > > > You can use kgdb and the scripts at www.freebsd.org/~jhb/gdb. > > > > > > Simply run 'kgdb' as root and do 'lcd /folder/with/scripts' and > > > > > > 'source gdb6'. You can then do 'lockchain 4283' to find who holds > > > > > > the lock this thread is blocked on and what state they are in. > > > > > > > > > > Looks like a deadlock: > > > > > > > > > > (kgdb) lockchain 4283 > > > > > thread 100215 (pid 4283, kdeinit4) blocked on lock 0xc64374a0 > > > > > "unp_mtx" thread 100122 (pid 1635, klauncher) blocked on lock > > > > > 0xc6806348 "unp_mtx" thread 100215 (pid 4283, kdeinit4) blocked on > > > > > lock 0xc64374a0 "unp_mtx" thread 100122 (pid 1635, klauncher) blocked > > > > > on lock 0xc6806348 "unp_mtx" thread 100215 (pid 4283, kdeinit4) > > > > > blocked on lock 0xc64374a0 "unp_mtx" thread 100122 (pid 1635, > > > > > klauncher) blocked on lock 0xc6806348 "unp_mtx" thread 100215 (pid > > > > > 4283, kdeinit4) blocked on lock 0xc64374a0 "unp_mtx" thread 100122 > > > > > (pid 1635, klauncher) blocked on lock 0xc6806348 "unp_mtx" thread > > > > > 100215 (pid 4283, kdeinit4) blocked on lock 0xc64374a0 "unp_mtx" > > > > > thread 100122 (pid 1635, klauncher) blocked on lock 0xc6806348 > > > > > "unp_mtx" thread 100215 (pid 4283, kdeinit4) blocked on lock > > > > > 0xc64374a0 "unp_mtx" thread 100122 (pid 1635, klauncher) blocked on > > > > > lock 0xc6806348 "unp_mtx" thread 100215 (pid 4283, kdeinit4) blocked > > > > > on lock 0xc64374a0 "unp_mtx" thread 100122 (pid 1635, klauncher) > > > > > blocked on lock 0xc6806348 "unp_mtx" thread 100215 (pid 4283, > > > > > kdeinit4) blocked on lock 0xc64374a0 "unp_mtx" thread 100122 (pid > > > > > 1635, klauncher) blocked on lock 0xc6806348 "unp_mtx" thread 100215 > > > > > (pid 4283, kdeinit4) blocked on lock 0xc64374a0 "unp_mtx" thread > > > > > 100122 (pid 1635, klauncher) blocked on lock 0xc6806348 "unp_mtx" > > > > > thread 100215 (pid 4283, kdeinit4) blocked on lock 0xc64374a0 > > > > > "unp_mtx" thread 100122 (pid 1635, klauncher) blocked on lock > > > > > 0xc6806348 "unp_mtx" DEADLOCK > > > > > > > > > > Looking through the scripts now to see how I can get more info on the > > > > > call chain and hoping I don't panic the machine ;). It is quite > > > > > random to reproduce. > > > > > > > > In kgdb you can simply do 'tid 100122' followed by 'bt' and 'tid > > > > 100215' followed by 'bt'. > > > > > > Cool, thanks for helping John. Of course it pretty much shows me what > > > procstat -k shows and can't get any info on the userland part, but I can > > > fully inspect the locks and threads. > > > > > > Both threads are in TDS_INHIBITED state, and blocked on: > > > (kgdb) frame 0 > > > #0 sched_switch (td=0xc5971240, newtd=0xc4d39900, flags=259) > > > at /usr/src/sys/kern/sched_ule.c:1864 > > > 1864cpuid = PCPU_GET(cpuid); > > > > That doesn't really tell us anything except that it isn't running. We know > > it is actually blocked on a lock, and we need the full stack trace to see > > where the two threads were trying to acquire the locks, hence 'bt'. ' > > procstat -k' output would be fine, too. > > the respective bt's: > (kgdb) tid 100122 > at /usr/src/sys/kern/kern_mutex.c:447 > #4 0xc06a68a5 in uipc_peeraddr (so=0xc64309a8, nam=0xe79a2c70) > at /usr/src/sys/kern/uipc_usrreq.c:682 > #5 0xc06a1e71 in kern_getpeername (td=0xc56e8900, fd=12, sa=0xe79a2c70, > alen=0xe79a2c6c) > at /usr/src/sys/kern/uipc_syscalls.c:1566 > > (kgdb) tid 100215 > (kgdb) bt > at /usr/src/sys/kern/kern_mutex.c:447 > #4 0xc06a68a5 in uipc_peeraddr (so=0xc6976338, nam=0xe9ae9c70) > at /usr/src/sys/kern/uipc_usrr
Re: small usr.bin/find patch
cheers. Are you sure this is wise? after all 125 millibytes would be 1 bit.. Agree. While lots of people use m instead of M and b instead of B, this is not right to correct proper behavior to improper just for them. ___ 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: How best to debug locking/scheduler problems
On Wednesday 17 June 2009 13:17:37 John Baldwin wrote: > On Wednesday 17 June 2009 3:52:54 pm Mel Flynn wrote: > > On Wednesday 17 June 2009 04:15:26 John Baldwin wrote: > > > On Tuesday 16 June 2009 7:01:45 pm Mel Flynn wrote: > > > > On Tuesday 16 June 2009 11:02:42 John Baldwin wrote: > > > > > On Tuesday 16 June 2009 1:52:23 pm Mel Flynn wrote: > > > > > > Hi John, > > > > > > > > > > > > On Tuesday 16 June 2009 04:19:57 John Baldwin wrote: > > > > > > > On Monday 15 June 2009 5:53:05 pm Mel Flynn wrote: > > > > > > > > PIDTID COMM TDNAME KSTACK > > > > > > > > 4283 100215 kdeinit4 -mi_switch > > > > > > > > turnstile_wait _mtx_lock_sleep uipc_peeraddr kern_getpeername > > > > > > > > getpeername syscall Xint0x80_syscall > > > > > > > > % ps -ww 4283 > > > > > > > > PID TT STAT TIME COMMAND > > > > > > > > 4283 ?? T 0:00.38 kdeinit4: kdeinit4: kio_http http > > > > > > > > local:/tmp/ksocket-mel/klauncherxJ1635.slave-socket > > > > > > > > local:/tmp/ksocket- mel/plasmayC1653.slave-socket (kdeinit4) > > > > > > > > > > > > > > > > %ls -l /tmp/ksocket-mel/ > > > > > > > > > > > > > > > > total 2 > > > > > > > > -rw-rw-r-- 1 mel wheel 62 Jun 14 22:55 KSMserver__0 > > > > > > > > srw--- 1 mel wheel 0 Jun 14 22:55 kdeinit4__0 > > > > > > > > srwxrwxr-x 1 mel wheel 0 Jun 14 22:55 > > > > > > > > klauncherxJ1635.slave-socket > > > > > > > > > > > > > > You can use kgdb and the scripts at www.freebsd.org/~jhb/gdb. > > > > > > > Simply run 'kgdb' as root and do 'lcd /folder/with/scripts' and > > > > > > > 'source gdb6'. You can then do 'lockchain 4283' to find who > > > > > > > holds the lock this thread is blocked on and what state they > > > > > > > are in. > > > > > > > > > > > > Looks like a deadlock: > > > > > > > > > > > > (kgdb) lockchain 4283 > > > > > > thread 100215 (pid 4283, kdeinit4) blocked on lock 0xc64374a0 > > > > > > "unp_mtx" thread 100122 (pid 1635, klauncher) blocked on lock > > > > > > 0xc6806348 "unp_mtx" thread 100215 (pid 4283, kdeinit4) blocked > > > > > > on lock 0xc64374a0 "unp_mtx" thread 100122 (pid 1635, klauncher) > > blocked > > > > > > > on lock 0xc6806348 "unp_mtx" thread 100215 (pid 4283, kdeinit4) > > > > > > blocked on lock 0xc64374a0 "unp_mtx" thread 100122 (pid 1635, > > > > > > klauncher) blocked on lock 0xc6806348 "unp_mtx" thread 100215 > > > > > > (pid 4283, kdeinit4) blocked on lock 0xc64374a0 "unp_mtx" thread > > > > > > 100122 (pid 1635, klauncher) blocked on lock 0xc6806348 "unp_mtx" > > > > > > thread 100215 (pid 4283, kdeinit4) blocked on lock 0xc64374a0 > > > > > > "unp_mtx" thread 100122 (pid 1635, klauncher) blocked on lock > > > > > > 0xc6806348 "unp_mtx" thread 100215 (pid 4283, kdeinit4) blocked > > > > > > on lock 0xc64374a0 "unp_mtx" thread 100122 (pid 1635, klauncher) > > > > > > blocked on lock 0xc6806348 "unp_mtx" thread 100215 (pid 4283, > > > > > > kdeinit4) blocked on lock 0xc64374a0 "unp_mtx" thread 100122 (pid > > > > > > 1635, klauncher) blocked on lock 0xc6806348 "unp_mtx" thread > > > > > > 100215 (pid 4283, kdeinit4) blocked on lock 0xc64374a0 "unp_mtx" > > > > > > thread 100122 (pid 1635, klauncher) blocked on lock 0xc6806348 > > > > > > "unp_mtx" thread 100215 (pid 4283, kdeinit4) blocked on lock > > > > > > 0xc64374a0 "unp_mtx" thread 100122 (pid 1635, klauncher) blocked > > > > > > on lock 0xc6806348 "unp_mtx" thread 100215 (pid 4283, kdeinit4) > > > > > > blocked on lock 0xc64374a0 "unp_mtx" thread 100122 (pid 1635, > > > > > > klauncher) blocked on lock 0xc6806348 "unp_mtx" DEADLOCK > > > > > > > > > > > > Looking through the scripts now to see how I can get more info on > > the > > > > > > > call chain and hoping I don't panic the machine ;). It is quite > > > > > > random to reproduce. > > > > > > > > > > In kgdb you can simply do 'tid 100122' followed by 'bt' and 'tid > > > > > 100215' followed by 'bt'. > > > > > > > > Cool, thanks for helping John. Of course it pretty much shows me what > > > > procstat -k shows and can't get any info on the userland part, but I > > > > can fully inspect the locks and threads. > > > > > > > > Both threads are in TDS_INHIBITED state, and blocked on: > > > > (kgdb) frame 0 > > > > #0 sched_switch (td=0xc5971240, newtd=0xc4d39900, flags=259) > > > > at /usr/src/sys/kern/sched_ule.c:1864 > > > > 1864cpuid = PCPU_GET(cpuid); > > > > > > That doesn't really tell us anything except that it isn't running. We > > know > > > > it is actually blocked on a lock, and we need the full stack trace to > > > see where the two threads were trying to acquire the locks, hence 'bt'. > > > ' procstat -k' output would be fine, too. > > > > the respective bt's: > > (kgdb) tid 100122 > > at /usr/src/sys/kern/kern_mutex.c:447 > > #4 0xc06a68a5 in uipc_peeraddr (so=0xc64309a8, nam=0xe79a2c70) > > at /usr/src/sys/kern/uipc_usrreq.c:682 > > #5 0xc06a1e71 in kern_getpeername (td=0xc56e8900, fd=12, sa=0xe79
Re: How best to debug locking/scheduler problems
On Wed, 17 Jun 2009, John Baldwin wrote:
These are the key frames. It looks like uipc_peeraddr() tries to lock two
unp locks w/o any protection from the global unp linkage lock. I've changed
it to use the same locking as uipc_accept() where it first grabs a read lock
on the linkage lock and then just locks the other end of the connection to
copy out its sockaddr.
This change looks reasonable to me, thanks for tracking this down!
Robert N M Watson
Computer Laboratory
University of Cambridge
--- //depot/user/jhb/socket/kern/uipc_usrreq.c
+++ /home/jhb/work/p4/socket/kern/uipc_usrreq.c
@@ -671,7 +671,7 @@
KASSERT(unp != NULL, ("uipc_peeraddr: unp == NULL"));
*nam = malloc(sizeof(struct sockaddr_un), M_SONAME, M_WAITOK);
- UNP_PCB_LOCK(unp);
+ UNP_LINK_RLOCK();
/*
* XXX: It seems that this test always fails even when connection is
* established. So, this else clause is added as workaround to
@@ -681,7 +681,7 @@
if (unp2 != NULL) {
UNP_PCB_LOCK(unp2);
if (unp2->unp_addr != NULL)
- sa = (struct sockaddr *) unp->unp_conn->unp_addr;
+ sa = (struct sockaddr *) unp2->unp_addr;
else
sa = &sun_noname;
bcopy(sa, *nam, sa->sa_len);
@@ -690,7 +690,7 @@
sa = &sun_noname;
bcopy(sa, *nam, sa->sa_len);
}
- UNP_PCB_UNLOCK(unp);
+ UNP_LINK_RUNLOCK();
return (0);
}
@@ -850,7 +850,7 @@
* return the slightly counter-intuitive but otherwise
* correct error that the socket is not connected.
*
-* Locking here must be done carefully: the inkage lock
+* Locking here must be done carefully: the linkage lock
* prevents interconnections between unpcbs from changing, so
* we can traverse from unp to unp2 without acquiring unp's
* lock. Socket buffer locks follow unpcb locks, so we can
--
John Baldwin
___
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"
CFT: final patches for NGROUPS>>16
Please find attached three patches which result in raising NGROUPS to
1024, making programs in the base system immune to changing values of
NGROUPS, and pave the way for NGROUPS to be boot time configurable.
The first two patches (ngroups-catman.diff and ngroups-posix.diff)
are userland cleanups. The third (ngroups-main.diff) is the core of
the change and primairly in the kernel. It is strongly based on work
contributed by Isilon Systems. The proposed commit messages appear to
the bottom of this message.
I've been running the basic code on my FreeBSD laptop for a while and
I've tested basic NFS mounts, but more areas need testing before this
hits a release. Key things to hit include:
- NFS mount and export
- IPFW uid, gid, and jail rules
- portalfs (ideally portalfs should be extended to not truncate groups)
In practice, expect appliations to not care about this change unless
they are run with more than 16 groups. If that happens, calls to
getgroups() will fail if they use statically sized buffers recompilation
should fix them.
Please test, review, etc. I'd like to get this in before code freeze if
at all possible.
-- Brooks
ngroups-catman.diff:
When checking if we can write to a file, use access() instead of a
manual permission check based on stat output. Also, get rid of the
executability check since it is not used.
MFC after:2 weeks
ngroups-posix.diff
In preparation for raising NGROUPS and NGROUPS_MAX, change base
system callers of getgroups(), getgrouplist(), and setgroups() to
allocate buffers dynamically. Specifically, allocate a buffer of size
sysconf(_SC_NGROUPS_MAX)+1 (+2 in a few cases to allow for overflow).
This (or similar gymnastics) is required for the code to actually follow
the POSIX.1-2008 specification where {NGROUPS_MAX} may differ at runtime
and where getgroups may return {NGROUPS_MAX}+1 results on systems like
FreeBSD which include the primary group.
In id(1), don't pointlessly add the primary group to the list of all
groups, it is always the first result from getgroups(). In principle
the old code was more portable, but this was only done in one of the two
places where getgroups() was called to the overall effect was pointless.
Document the actual POSIX requirements in the getgroups(2) and
setgroups(2) manpages. We do not yet support a dynamic NGROUPS, but we
may in the future.
MFC after:2 weeks
ngroups-main.diff:
Rework the credential code to support larger values of NGROUPS and
NGROUPS_MAX, eliminate ABI dependencies on them, and raise the to 1024
and 1023 respectively. (Previously they were equal, but under a close
reading of POSIX, NGROUPS_MAX was defined to be too large by 1 since it
is the number of supplemental groups, not total number of groups.)
The bulk of the change consists of converting the struct ucred member
cr_groups from a static array to a pointer. Do the equivalent in
kinfo_proc.
Introduce new interfaces crcopysafe() and crsetgroups() for duplicating
a process credential before modifying it and for setting group lists
respectively. Both interfaces take care for the details of allocating
groups array. crsetgroups() takes care of truncating the group list
to the current maximum (NGROUPS) if necessary. In the future,
crsetgroups() may be responsible for insuring invariants such as sorting
the supplemental groups to allow groupmember() to be implemented as a
binary search.
Because we can not change struct xucred without breaking application
ABIs, we leave it alone and introduce a new XU_NGROUPS value which is
always 16 and is to be used or NGRPS as appropriate for things such as
NFS which need to use no more than 16 groups. When feasible, truncate
the group list rather than generating an error.
Minor changes:
- Reduce the number of hand rolled versions of groupmember().
- Do not assign to both cr_gid and cr_groups[0].
- Modify ipfw to cache ucreds instead of part of their contents since
they are immutable once referenced by more than one entity.
Submitted by: Isilon Systems
X-MFC after: never
pgpAxsH2CKHzy.pgp
Description: PGP signature
Re: valgrind on FreeBSD 7
Jeroen Ruigrok van der Werven wrote: I have been working on/off on it. I am trying to find my work in progress sources, but I think they got lost when a hard disk died. This is all I have found: http://www.in-nomine.org/~asmodai/valgrind/valgrind-trunk-for-freebsd.diff Any news on valgrind for FreeBSD? Also is there a way to check it out from the server? Is it on perforce? I believe there is no easy way to even get it read-only without user id. So are there snapshots somewhere? 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: small usr.bin/find patch
+--- Julian Elischer, 2009-06-17 --- | Alexander Best wrote: | >hi everybody, | > | >here's just a quick hack i applied to find. i very often use the -size | >switch | >and always forget if you need to append "m" or "M" for megabyte or "k" or | >"K" | >for kilobyte. after applying the patch find accepts both. ;-) | > | >cheers. | > | | Are you sure this is wise? after all 125 millibytes would be 1 bit.. | | ( :-) ) BTW, our du(1) accepts only lowercase -k and -m. ___ 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"
good morning to all
how to install samba in freebsd advance thanks ___ 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"
