unique hardware identification
Hi All, I was wondering, if something like a unique hardware identification would be possible on FreeBSD. I'd like a machine to authenticate to a server, for which it will need a unique identification. Problem is, it should be generated automatically and not easy to fake / detect without already having root access to the box. I'm thinking of something like combining serial numbers from CPU/disks for example, but there does not seem to be a clear way to obtain these (not all cpu's even have a serial number in there). I am just inquiring if someone on this list has an idea that might help with this problem. Gr, Koen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RELENG-5 20050101 panic
Hi All, I am wondering if the trace below rings a bell to someone. I'm trying to find out what is wrong with 5.4 on a certain box i have (see panic in propagate priority thread earlier on). Since debugging did not seem to help much, i'm now trying the hard way: cvsupping kernels from RELENG-5 at points along the 5.3 -- 5.4 dates, effectivelly doing a binary search to pinpoint where the problem was introduced (5.3 runs fine on the problem boxes). But now i am getting the trace below, since it is different from what I had before, i am wondering if this is maybe some bug that got fixed long ago. The kernel i have running now is from 2005-01-01. For some more info on my original problem, i put some stuff online at http://www.sonologic.nl/fbsd/. Best, Koen (ps, upgrading to 6.x is not an option at this point, since i now it to be running fine on 5.3 but not on 5.4, i want to find out first whether this particular unstability was fixed in 6.x because once i'm on 6.x, downgrading to 5.3 is less feasible if things turn out to go even worse) Limiting closed port RST response from 247 to 200 packets/sec Limiting closed port RST response from 237 to 200 packets/sec mode = 0100600, inum = 652933, fs = /var panic: ffs_valloc: dup alloc cpuid = 1 KDB: stack backtrace: kdb_backtrace(100,c32567d0,c58e8e38,603,c3086000) at kdb_backtrace+0x29 panic(c069abcc,c069abab,8180,9f685,c30860d4) at panic+0x114 ffs_valloc(c3b8,8180,c32d7680,e8fc0900,e8fc094c) at ffs_valloc+0x149 ufs_makeinode(8180,c3b8,e8fc0bf8,e8fc0c0c) at ufs_makeinode+0x59 ufs_create(e8fc0a84,e8fc0b40,c0552c20,e8fc0a84,d6ea7648) at ufs_create+0x26 ufs_vnoperate(e8fc0a84) at ufs_vnoperate+0x13 vn_open_cred(e8fc0be4,e8fc0ce4,180,c32d7680,18a) at vn_open_cred+0x174 vn_open(e8fc0be4,e8fc0ce4,180,18a,c3f1b000) at vn_open+0x1e kern_open(c32567d0,97fca20,0,603,180) at kern_open+0xe3 open(c32567d0,e8fc0d14,3,c65,286) at open+0x18 syscall(2f,2f,bfbf002f,602,180) at syscall+0x283 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (5, FreeBSD ELF32, open), eip = 0x283876bb, esp = 0xbfbfd01c, ebp = 0xbfbfd048 --- KDB: enter: panic [thread 100185] Stopped at kdb_enter+0x2b: nop db continue -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, hosting, embedded systems, unix, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH From within a Jail
Koen Martens wrote: d c wrote: Greetings: I currently am running Freebsd 6.0 Release. I am experimenting with jails and have run into a problem. I need to ssh from within my jail to another server. Actually I need to use scp. WHen I try it I get the error: Host key verification failed. This could also be something related to permissions on the .ssh directory, but you cleared that out of the way if i understand the rest of this thread correctly. I remember having this problem once, but can't remember right now what i did to solve it.. I usually compile openssh from source anyway, so you might try that. If that works, it would probably be interesting to see what is the difference between your own hand-rolled openssh and the one that came with your world. Just remembered something else: do you jexec into the jail, or do you do a proper logon (eg. ssh into the jail). I think that if you jexec into the jail and then try to ssh, you might have a problem because you aren't really logged in to the jail and thus have no (psuedo) tty associated with your session.. Koen -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, hosting, embedded systems, unix, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SSH From within a Jail
d c wrote: Greetings: I currently am running Freebsd 6.0 Release. I am experimenting with jails and have run into a problem. I need to ssh from within my jail to another server. Actually I need to use scp. WHen I try it I get the error: Host key verification failed. This could also be something related to permissions on the .ssh directory, but you cleared that out of the way if i understand the rest of this thread correctly. I remember having this problem once, but can't remember right now what i did to solve it.. I usually compile openssh from source anyway, so you might try that. If that works, it would probably be interesting to see what is the difference between your own hand-rolled openssh and the one that came with your world. Koen -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, hosting, embedded systems, unix, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Backup methodes
Thomas Hurst wrote: * Carlos Silva aka |Danger_Man| ([EMAIL PROTECTED]) wrote: what is the best method to backup network information and local disk information with another disk? dump/restore performs snapshotted incremental backups of complete filesystems. I've been using dar (http://dar.linux.free.fr/) for a while now and very happy with it. Works on the filesystem level, not on the block device level, and does incremental backups, also of parts of your filesystem and to a remote machine (through ssh for example). Whether it is the best method for you, i can't answer. Koen -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, hosting, embedded systems, unix, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic in propagate_priority w/ postgresql under heavy load
Robert Watson wrote: On Sun, 2 Oct 2005, Koen Martens wrote: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 06 fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc051c253 stack pointer = 0x10:0xe93efb3c frame pointer = 0x10:0xe93efb50 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 6092 (postgres) And that, that is all.. No ddb no 'dumping MB', just that. So basically, i fear this is a non-debugable problem, since putting in witness and such slows the kernel to a point where the panic does not occur anymore (at least, not in the 4 weeks i've been running the box with witness invariants). Clueless :) This looks like a NULL pointer dereference in kernel code. Probably, this is not a locking problem, so running without WITNESS to debug this should be OK. Are you using a serial console? If not, you might find that it increases the reliability of entering DDB. If this box is an SMP box, you may also want to add options KDB_STOP_NMI to your kernel config. Using gdb, could you work out what function 0xc051c253 is, and where in the function. You should be able to run gdb on your kernel.debug (or kernel on 7.x), and use l *0xc051c253 to generate a pointer to the line and snippet, which will give us a substantial hint about what is happening. Sorry for not getting back on this timely, have had rather a busy period (lousy excuse, i know). Anyway, I have currently downgraded the machine to a 5.3-RELEASE-p22 kernel, which seems to have solved the problem. There are no panics anymore (it has been two weeks since the downgrade). Makes me a bit warry about upgrading anything to 6.x :) Anyway, i did get into the ddb prompt on one of the last panics, and put some of the resources online: http://www.sonologic.nl/fbsd/ As you can see, i was pretty clueless about what to do, and just traced about everything that was not swapped out.. Did not put the core dump online, as i don't feel like sharing that with the world. Available upon request though for those who want to get a crack at this. I don't have a copy of the kernel.debug lying around, for which I apologise. I cannot however upgrade to 5.4 again, we've had enought trouble with this machine and the user load on that machine has increased to a point where i cannot afford these random panics anymore. I don't have the spare identical hardware lying around at this point to copy the entire setup for testing purposes.. What i will try when i find some time is doing incremental upgrades from 5.3-RELEASE-p22 to 5.4-RELEASE-p6, step by step, to see what patchlevel introduces the problem. Best, Koen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic in propagate_priority w/ postgresql under heavy load
Robert Watson wrote: On Sun, 2 Oct 2005, Koen Martens wrote: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 06 fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc051c253 stack pointer = 0x10:0xe93efb3c frame pointer = 0x10:0xe93efb50 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 6092 (postgres) And that, that is all.. No ddb no 'dumping MB', just that. So basically, i fear this is a non-debugable problem, since putting in witness and such slows the kernel to a point where the panic does not occur anymore (at least, not in the 4 weeks i've been running the box with witness invariants). Clueless :) This looks like a NULL pointer dereference in kernel code. Probably, this is not a locking problem, so running without WITNESS to debug this should be OK. Are you using a serial console? If not, you might find that it increases the reliability of entering DDB. If this box is an SMP box, you may also want to add options KDB_STOP_NMI to your kernel config. Using gdb, could you work out what function 0xc051c253 is, and where in the function. You should be able to run gdb on your kernel.debug (or kernel on 7.x), and use l *0xc051c253 to generate a pointer to the line and snippet, which will give us a substantial hint about what is happening. Sorry for not getting back on this timely, have had rather a busy period (lousy excuse, i know). Anyway, I have currently downgraded the machine to a 5.3-RELEASE-p22 kernel, which seems to have solved the problem. There are no panics anymore (it has been two weeks since the downgrade). Makes me a bit warry about upgrading anything to 6.x :) Anyway, i did get into the ddb prompt on one of the last panics, and put some of the resources online: http://www.sonologic.nl/fbsd/ As you can see, i was pretty clueless about what to do, and just traced about everything that was not swapped out.. Did not put the core dump online, as i don't feel like sharing that with the world. Available upon request though for those who want to get a crack at this. I don't have a copy of the kernel.debug lying around, for which I apologise. I cannot however upgrade to 5.4 again, we've had enought trouble with this machine and the user load on that machine has increased to a point where i cannot afford these random panics anymore. I don't have the spare identical hardware lying around at this point to copy the entire setup for testing purposes.. What i will try when i find some time is doing incremental upgrades from 5.3-RELEASE-p22 to 5.4-RELEASE-p6, step by step, to see what patchlevel introduces the problem. Best, Koen -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, hosting, embedded systems, unix, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic in propagate_priority w/ postgresql under heavy load
Robert Watson wrote: I can't speak to the problem with the core dumps, as it sounds like that is device/firmware related. However, I probably can lend a hand in debugging the problems you're seeing. I don't think the dump problem is device/firmware related, as a reboot -d gives me a dump just fine. Often, this means the actual panic or failure has not occurred in the thread that prints out the panic you see, but another panic. So the first task on hitting a propagate_priority() panic is to identify the thread that actually had the problem. Hmmm, so we have a very elusive problem here, one that is not easily pinpointed.. Somehow, this does not come as a surprise :) If you want to do this by e-mail so we can lend a hand, you probably want to hook up a serial console so you can copy and paste the debugging session. Compile DDB into the kernel (this should have no performance overhead), and when the system panics, you'll (ideally) get a db prompt. [excellent help in debugging deleted for brevity] Right, so perhaps i am missing something here, but this in my kernel config should do it (full config included below for completeness sake, as well as dmesg output): # debug options KDB options DDB # options KDB_TRACE # makeoptions DEBUG=-g # debug Furthermore, since reboot -d does dump to swap now (by limiting physical memory to just below the swap partition size in the bootloader config), i would expect to get a dump also when a panic occurs, and i would expect a ddb prompt. Alas, this is what i get: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 06 fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc051c253 stack pointer = 0x10:0xe93efb3c frame pointer = 0x10:0xe93efb50 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 6092 (postgres) And that, that is all.. No ddb no 'dumping MB', just that. So basically, i fear this is a non-debugable problem, since putting in witness and such slows the kernel to a point where the panic does not occur anymore (at least, not in the 4 weeks i've been running the box with witness invariants). Clueless :) Best, Koen [ full kernel config: # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.413.2.13 2005/04/02 16:37:58 scottl Exp $ machine i386 cpu I486_CPU cpu I586_CPU cpu I686_CPU ident YIN-YANG # debug #options WITNESS #options INVARIANTS #optionsINVARIANT_SUPPORT options KDB options DDB # options KDB_TRACE # makeoptions DEBUG=-g # debug # To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints # Default places to look for devices. options SCHED_4BSD # 4BSD scheduler options INET# InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT# NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_GPT# GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with
Re: panic in propagate_priority w/ postgresql under heavy load
Vinod Kashyap wrote: You seem to be booting off of a 9000 (twa) controller and not 7000/8000 (twe). It could be because of a 9000 firmware bug that you are not being able to get the dump. The firmware wrongly interprets physical address 0x0 as invalid during dumps, and fails the operations. This bug will be fixed in future firmware releases. Ok, it's been a while, here is an update on this. I ran a heavily instrumented kernel for two weeks on the server, it did not crash in that time. I then took out the witness and kdb/ddb stuff, because the decreased performance was a bit of a nuisance, however i retained the ability to obtain a crash dump. I had to limit physical memory, put it on 1.8GB in loader.conf:hw.physmem because swap and physmem are both 2GB. Tested with 'reboot -d' gave me a core dump. Without the debug stuff in the kernel, it crashed within 2 days, same story: postgresql process, function propagate_priority. However, no dump was written to disk :( Furthermore, i've been seeing the same crash (in propagate_priority) on another box in mysql processes. Both servers seem to panic every 2-3 days. I have another server of the exact same hardware configuration, but it is mainly idling most of the time. Haven't seen that one crash yet. I am thinking now that it is a bug in the twa driver, so i'll have to dig in to that. Furthermore, it seems to have to do with some sort of concurrency issue or otherwise timing-sensitive issue, because slowing the kernel down with debug code seems to avoid the panic. But, as i am completely new to the freebsd kernel and don't even know what turnstiles are, i imagine i will have a hard time. So if anyone can offer some help, please :) Ok, thanks for your attention, Koen -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, hosting, embedded systems, unix, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic in propagate_priority w/ postgresql under heavy load
Vinod Kashyap wrote: You seem to be booting off of a 9000 (twa) controller and not 7000/8000 (twe). It could be because of a 9000 firmware bug that you are not being able to get the dump. The firmware wrongly interprets physical address 0x0 as invalid during dumps, and fails the operations. This bug will be fixed in future firmware releases. Indeed am I booting of twa, swap is also on there. Just got back from vacation, we did have another panic. The box was booted into single user mode right after that, after which an image of the swap partition was made with dd. When I got back, i turned of swap momentarily and dd'ed the image back on the swap partition, after which i ran savecore. However, savecore reports 'no dumps found'. With the -f option it also says: 'unable to force dump - bad magic' (Note: swap is 2048mb, physical memory is also 2048mb). So basically, what i'm left with now is a production server that crashes every x days, possibly resulting in some database corruption, and no way to obtain more info about the crash than i have already provided... I will try and install a comparable setup on a spare box, without the twa (plain IDE) and see if i can reproduce something, if i can find some time to do this in. I will also try bumping the witness limits. What is this witness business anyway, what does it output and/or where do i RTFM about it? Gr, Koen -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, hosting, embedded systems, unix, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
panic in propagate_priority w/ postgresql under heavy load
Hi Hackers, I've had a little chat with neologism on ircnet/#freebsd about this already, and done as he suggested: compile a debug kernel to obtain a stack trace. Anyway, what is happening is that there is a crash when running postgresql 8.0.3 with a very large database and doing heavy queries. Kernel is 5.4-RELEASE-p6 (5.4-RELENG i checked out tuesday a week ago). Kernel conf is down below. Here is the message i get on the console: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 06 fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc050cff7 stack pointer = 0x10:0xe99c2b0c frame pointer = 0x10:0xe99c2b20 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 4571 (postgres) It has been a postgres process in all of the observed cases. I've looked it up with gdk on my kernel.debug, here's what i get: = yin# gdb kernel.debug GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... (gdb) l *propagate_priority+0x7f 0xc050cff7 is in propagate_priority (/usr/src/sys/kern/subr_turnstile.c:245). 240 /* 241 * Pick up the lock that td is blocked on. 242 */ 243 ts = td-td_blocked; 244 MPASS(ts != NULL); 245 tc = TC_LOOKUP(ts-ts_lockobj); 246 mtx_lock_spin(tc-tc_lock); 247 248 /* 249 * This thread may not be blocked on this turnstile anymore (gdb) = So the next thing you'll ask for is a stack trace, but i haven't been able to obtain one. According to the freebsd handbook (http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-gdb.html) there should be a core dump in /var/crash, but there is none and the handbook chapter seems outdated anyway judging by it mentioning kgdb... Anyway, it seems the dump should've gone to the swap partition, but i'm into multi-user mode again so i guess i'll have to wait for another panic to obtain it? I'm not very knowledgeable about the freebsd kernel internals (yet), so i'm not sure what could be wrong here.. I hope some of you can provide some insight, and ideally a fix :) ==[ kernel config: # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.413.2.13 2005/04/02 16:37:58 scottl Exp $ machine i386 cpu I486_CPU cpu I586_CPU cpu I686_CPU ident YIN-YANG # debug options WITNESS options KDB options DDB # makeoptions DEBUG=-g # debug # To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints # Default places to look for devices. options SCHED_4BSD # 4BSD scheduler options INET# InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT# NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS
Re: panic in propagate_priority w/ postgresql under heavy load
John Baldwin wrote: On Thursday 01 September 2005 01:02 pm, Koen Martens wrote: I've had a little chat with neologism on ircnet/#freebsd about this already, and done as he suggested: compile a debug kernel to obtain a stack trace. Can you reproduce it with a kernel that has INVARIANTS and INVARIANT_SUPPORT on? I see that you had WITNESS on, can you check to see if there were any witness messages about sleepign with non-sleepable locks held before the crash? I will do this when I get back. I did a grep -i on witness in the console log but this did not turn up anything suspicious (exact output pasted below). Also, i checked again the logs right before the crashes, nothing special output to console before the Kernel trap 12.. voltaire# grep -i witness yin.log WARNING: WITNESS option enabled, expect reduced performance. witness_get: witness exhausted WARNING: WITNESS option enabled, expect reduced performance. witness_get: witness exhausted Gr, Koen -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, hosting, embedded systems, unix, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic in propagate_priority w/ postgresql under heavy load
Hi Dim, Dimitry Andric wrote: On 2005-09-01 at 19:02:06 Koen Martens wrote: Anyway, it seems the dump should've gone to the swap partition, but i'm into multi-user mode again so i guess i'll have to wait for another panic to obtain it? In RELENG_6, the dump device is chosen automagically during boot by /etc/rc.d/dumpon, but this is (alas) not the case in RELENG_5_x, so you'll have to manually specify it in /etc/rc.conf, i.e: dumpdev=/dev/ad0s1b Then make sure you have enough space in /var/crash, and try to reproduce your panic... Ok, i get it.. When it reboots it detects a dump on the swap partition and dd's that to /var/crash.. Which has plenty of free space on the particular box, 59 gigs ought to be enough for everyone :) Also, I think I read somewhere that there used to be problems with dumping and 3Ware RAID cards (you seem to be using one according to your kernel config, but you apparently didn't post a dmesg). You're right, dmesg included below. However, it looks like revision 1.22.2.1 of src/sys/dev/twe/twe.c fixed that: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/twe/twe.c?rev=1.22.2.1content-type=text/x-cvsweb-markup Just to be sure, can you check if you got this version of twe.c, or 1.22.2.2 (which seems to be the RELENG_5_4 version, and thus it should be fixed). * $FreeBSD: src/sys/dev/twe/twe.c,v 1.22.2.2 2005/02/18 18:42:16 vkashyap Exp $ (nice wrapping, i think you get the idea :) dmesg: Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-RELEASE-p6 #1: Thu Sep 1 14:06:03 CEST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/yin-yang-5.4 WARNING: WITNESS option enabled, expect reduced performance. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.06GHz (3056.50-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf29 Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs real memory = 2146959360 (2047 MB) avail memory = 2095415296 (1998 MB) ACPI APIC Table: PTLTD APIC FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard ioapic2 Version 2.0 irqs 48-71 on motherboard npx0: math processor on motherboard npx0: INT 16 interface acpi0: PTLTD RSDT on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: unknown at device 0.1 (no driver attached) pcib1: ACPI PCI-PCI bridge at device 2.0 on pci0 pci1: ACPI PCI bus on pcib1 pci1: base peripheral, interrupt controller at device 28.0 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 29.0 on pci1 pci2: ACPI PCI bus on pcib2 pci1: base peripheral, interrupt controller at device 30.0 (no driver attached) pcib3: ACPI PCI-PCI bridge at device 31.0 on pci1 pci3: ACPI PCI bus on pcib3 3ware device driver for 9000 series storage controllers, version: 2.50.02.012 twa0: 3ware 9000 series Storage Controller port 0x7000-0x70ff mem 0xfd80-0xfdff,0xfb20-0xfb2000ff irq 48 at device 1.0 on pci3 twa0: 4 ports, Firmware FE9X 2.02.00.008, BIOS BE9X 2.02.01.037 pci0: unknown at device 2.1 (no driver attached) pcib4: ACPI PCI-PCI bridge at device 30.0 on pci0 pci4: ACPI PCI bus on pcib4 pci4: display, VGA at device 3.0 (no driver attached) fxp0: Intel 82550 Pro/100 Ethernet port 0x8400-0x843f mem 0xfb30-0xfb31,0xfb341000-0xfb341fff irq 20 at device 4.0 on pci4 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:02:b3:d8:8a:b5 em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.35 port 0x8440-0x847f mem 0xfb32-0xfb33 irq 23 at device 5.0 on pci4 em0: Ethernet address: 00:02:b3:d8:8b:05 em0: Speed:N/A Duplex:N/A isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH3 UDMA100 controller port 0x6c60-0x6c6f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 pci0: serial bus, SMBus at device 31.3 (no driver attached) acpi_button0: Power Button on acpi0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: floppy drive controller port 0x3f7,0x3f4-0x3f5,0x3f0-0x3f3 irq 6 drq 2 on acpi0 fd0: 1440-KB 3.5 drive on fdc0 drive 0 sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A
Re: Jail + sysv shmem
On Sun, Nov 28, 2004 at 12:00:58PM +, [EMAIL PROTECTED] wrote: From: Justin Hopper [EMAIL PROTECTED] I know that Pawel @ http://garage.freebsd.pl has a patch for making private SysV IPC memory spaces for the host system and each jail: http://garage.freebsd.pl/privipc.README The patch is against 4.x though, and I've never tried it. I would really like to see something like this implemented for 5.x though. Does anyone know if there are plans to implement this in the future 5.x releases? If not, I would be interested in helping anyone that wishes to try implementing this in 5.3 soon, as we have a lot of clients who ask for SysV IPC inside of jailed hosting environments. Interesting, I will download that and see if it is of any help in my effort to implementing this in freebsd 5.x. Thanks for the pointer. -- Date: Sun, 28 Nov 2004 18:21:06 +1100 From: Peter Jeremy [EMAIL PROTECTED] The sysadmin is likely to need access to: 1) look at SysV IPC usage across the entire system 2) clean up after a process has died unexpectedly. Whilst it's possible for the sysadmin to enter the relevant jail and look at what is used in that jail, it's very difficult to get an overall view of the system in this way - especially if there are lots of jails. Hmm, there is a trade-off: ease of maintenance vs security. I personally would not want to have the host system to have access to the jail systems by IPC. It seems reasonable to make this a sysctl (which can only be set at boot time). Robert Watson was also looking into this recently. I had some contact with him a while back, about his jailng project. However, that has been abandonded afaik. How recently have you heard him talk about this? Kind regards, Koen Martens -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, embedded systems, unix expertise, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Jail + sysv shmem
On Fri, Nov 26, 2004 at 10:58:43PM +0100, Jilles Tjoelker wrote: You will have trouble if two jails want to use the same IPC key (key_t, usually a long). This can also happen in rare cases when running multiple programs (unjailed) that all try to use separate SysV IPC. Hmm.. Yes.. In the jail case, this can be abused by attackers by (easily) guessing the key that an application in another jail will use and using it in their own jail. The attacker will have to do this before the application is started, or at almost any time if the application does not run all the time. But, when access to the shared resource is denied on the basis of the jail identifier, at least cross-jail attacks are not allowed anymore. Additionally, certain methods to generate IPC keys may give the same result in several jails. A common method to generate them is ftok(3). This uses the lower 8 bits of the st_dev and the lower 16 bits of the inode number. Therefore, you will get in trouble with hundreds of similar jails with their own mount. Quite right, this is actually a documented bug of the ftok method. And having multiple jails makes this a problem. However, when a IPC segment identifier is always a tuple of jail-id + user key, no clashes should exist, only within the same jail (and this is unavoidable). To avoid these problems, every jail and the outside system would need their own IPC key space. This is harder to implement and makes access from the outside system to jailed IPC impossible. Alas, that's how ATT's engineers designed SysV IPC decades ago. Why would one want access from the outside system to the jailed system? Is this something that is used frequently? Me personally, i want to keep everything as seperated as possible. Obviously, the host system can always access the jail file systems, but I do want to prevent the host system to have IPC xx to the jails. My main motivation btw is to be able to run postgres in a jail, which can only be done by enabling shared mem inside jails, which is not really an option i think. Alternatively, one can run the postgres server in the host system, but that is not a good solution either. I'll just start hacking soon, and see where it leads me :) Koen -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, embedded systems, unix expertise, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Jail + sysv shmem
Hello Hackers,
For a while i've been wanting shared memory to be usable withing jails,
but with cross-jail protection. Ie. shared memory is restricted to a
jail.
Recently I've been digging a bit in the freebsd kernel source code
(which is new to me, been doing quite some linux kernel hacking though).
It looks like this is actually not _that_ difficult to implement.
So, did anyone try this yet? Any pointers?
I think it can be done by putting the jail id in struct ipc_perm (in
sys/ipc.h), and then basically editing sysv_{msg,sem,shm}.c to extend
these checks that are all over there:
if (!jail_sysvipc_allowed jailed(td-td_ucred))
return (ENOSYS);
Does that sound ok?
Kind regards,
Koen
--
K.F.J. Martens, Sonologic, http://www.sonologic.nl/
Networking, embedded systems, unix expertise, artificial intelligence.
Public PGP key: http://www.metro.cx/pubkey-gmc.asc
Wondering about the funny attachment your mail program
can't read? Visit http://www.openpgp.org/
pgp1E5Qc7KO3s.pgp
Description: PGP signature
