Kernel panic on PowerEdge 1950 under certain stress load
Hi FreeBSD hackers and engineers, I am experiencing a kernel panic that comes on when my new PowerEdge 1950 FreeBSD 6.2 setup is under a certain stress load. I've emailed a few people on the list who have given me useful comments, some of which I am still following up. But I wanted to send a general cry for help to see if there are more knowledge out there about this problem. FreeBSD 6.2 on PowerEdge 1950, RAID1 setup with mfi driver (PERC5i). 4GB RAM. I am currently running i386, and not amd64, due to various reasons. I've ran exhaustively memory tests, disk tests, and network tests and cannot produce the kernel panic. I worked with Dell support to run memory test 1 DIMM at a time and cannot find any problem. With 1 DIMM at a time, I could still get the kernel panic under my work load. My work load is heavily hitting a web site running on the machine and requiring the web service to do MySQL requests. On the side, I am running a bunch of scripts that mostly read from the MySQL database but also write to it occasionally. Not memory intensive -- still have usually about 1GB free memory, but fairly disk intensive. I don't get disk errors. Anywhere from between 10 minutes to 4 or 5 hours into the test, I get the kernel panic. Again, still no disk errors. I turned off soft-update, still happens. Kernel panic is at 0xC066C731, which from nm shows it's in mtx_lock_spin c066c7b4 T _mtx_lock_spin c066c85c T _mtx_unlock_sleep So this could mean that independent stress tests will not result in panic if there aren't enough concurrency to cause the problem. There are a few other complaints about kernel panics at the same IP on the web (google 0xc066c731)... I was wondering if anyone had dealt with this before and if there are any work arounds? Thanks, Benjie ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel panic on PowerEdge 1950 under certain stress load
On 22 Sep 2007, at 00:26, Benjie Chen wrote: FreeBSD 6.2 on PowerEdge 1950, RAID1 setup with mfi driver (PERC5i). 4GB RAM. I am currently running i386, and not amd64, due to various reasons. Kernel panic is at 0xC066C731, which from nm shows it's in mtx_lock_spin c066c7b4 T _mtx_lock_spin c066c85c T _mtx_unlock_sleep So this could mean that independent stress tests will not result in panic if there aren't enough concurrency to cause the problem. I don't have the exact IP address involved, but we experienced consistent panics in two heavily loaded mail servers (same hardware models, Dell Powereedge) runnning Postfix and FreeBSD 6.2. Suspecting an issue with the IP stack and smp I tried to set debug.mpsafenet=0 and the problems are gone. Of course I've lost some performance, but the systems have been solid for some weeks so far. Borja. The thing he realised about the windows was this: because they had been converted into openable windows after they had first been designed to be impregnable, they were, in fact, much less secure than if they had been designed as openable windows in the first place. Douglas Adams, Mostly Harmless ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
linuxolator problem on i386
Hi # su hlds -c ktrace -i ./hlds_run -game cstrike +ip 0.0.0.0 +port 27015 +map de_dust -debug Auto detecting CPU Using Pentium II Optimised binary. Enabling debug mode Auto-restarting the server on crash Console initialized. scandir failed:/usr/home/hlds/1.6/./platform/SAVE Protocol version 47 Exe version 1.1.2.5/Stdio (cstrike) Exe build: 20:02:49 Oct 24 2006 (3651) STEAM Auth Server couldn't exec language.cfg Server IP address 0.0.0.0:27015 scandir failed:/usr/home/hlds/1.6/./platform/SAVE *** glibc detected *** ./hlds_i686: double free or corruption (!prev): 0x08da3738 *** === Backtrace: = /lib/libc.so.6[0x2811ac88] /lib/libc.so.6(cfree+0x90)[0x2811e230] /lib/libc.so.6(closedir+0x28)[0x2813ecf8] /lib/libc.so.6(scandir+0x14b)[0x2813f21b] /usr/home/hlds/1.6/filesystem_stdio_i386.so(findFileInDirCaseInsensitive__FPCc+0xe4)[0x28af41d8] /usr/home/hlds/1.6/filesystem_stdio_i386.so(FS_stat__17CFileSystem_StdioPCcP4stat+0x40)[0x28af861c] /usr/home/hlds/1.6/filesystem_stdio_i386.so(FastFindFileSize__15CBaseFileSystemPCQ215CBaseFileSystem11CSearchPathPCc+0x17e)[0x28af572a] /usr/home/hlds/1.6/filesystem_stdio_i386.so(Size__15CBaseFileSystemPCc+0x5b)[0x28af557b] /usr/home/hlds/1.6/engine_i686.so(FS_FileSize+0x2a)[0x2828679e] === Memory map: 08048000-08054000 r-xp 0003a000 00:00 1931338 /usr/home/hlds/1.6/hlds_i686 08054000-0805b000 rw-p 0003a000 00:00 1931338 /usr/home/hlds/1.6/hlds_i686 0805b000-0805e000 rw-p 00d6 00:00 0 0805e000-08dbb000 rwxp 00d6 00:00 0 28054000-2806d000 r-xp 0001e000 00:00 1719480 /usr/compat/linux/lib/ld-2.5.so 2806d000-2806e000 r-xp 0001e000 00:00 1719480 /usr/compat/linux/lib/ld-2.5.so 2806e000-2806f000 rw-p 2000 00:00 0 2806f000-2807 rwxp 2000 00:00 0 28071000-28073000 r-xp 4000 00:00 1719493 /usr/compat/linux/lib/libdl-2.5.so 28073000-28074000 r-xp 4000 00:00 1719493 /usr/compat/linux/lib/libdl-2.5.so 28074000-28075000 rwxp 4000 00:00 1719493 /usr/compat/linux/lib/libdl-2.5.so 28075000-28076000 rwxp 1000 00:00 0 28076000-28088000 r-xp 0001e000 00:00 1719511 /usr/compat/linux/lib/libpthread-2.5.so 28088000-28089000 r-xp 0001e000 00:00 1719511 /usr/compat/linux/lib/libpthread-2.5.so 28089000-2808a000 rwxp 0001e000 00:00 1719511 /usr/compat/linuxAbort trap (core dumped) debug.cmds:1: Error in sourced command file: Previous frame inner to this frame (corrupt stack?) email debug.log to linux at valvesoftware.com http://lists.freebsd.org/mailman/listinfo/freebsd-emulation Wed Sep 12 20:27:04 SAMST 2007: Server restart in 10 seconds Wed Sep 12 20:27:06 SAMST 2007: Server Quit # === # uname -a FreeBSD damask 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Wed Sep 12 17:04:55 SAMST 2007 root at cs.udmvt.ru http://lists.freebsd.org/mailman/listinfo/freebsd-emulation:/usr/obj/usr/src/sys/CS2 i386 # sysctl compat compat.linux.oss_version: 198144 compat.linux.osrelease: 2.6.16 compat.linux.osname: Linux # kldstat Id Refs AddressSize Name 1 14 0xc040 3e6ee0 kernel 21 0xc07e7000 69514acpi.ko 31 0xc3ddd000 7000 linprocfs.ko 42 0xc3de4000 21000linux.ko 51 0xc3e0e000 3000 linsysfs.ko # mount|grep linux linprocfs on /usr/compat/linux/proc (linprocfs, local) linsysfs on /usr/compat/linux/sys (linsysfs, local) # pkg_info | grep linux linux_base-fc6-6_3 Base set of packages needed in Linux mode (for i386/amd64) [private links to debug.log ktrace.out] please send me message after downloaded this files (for removing) /Vladimir Ermakov cross-posting: http://lists.freebsd.org/pipermail/freebsd-emulation/2007-September/003960.html ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel panic on PowerEdge 1950 under certain stress load
Borja Marcos wrote: On 22 Sep 2007, at 00:26, Benjie Chen wrote: FreeBSD 6.2 on PowerEdge 1950, RAID1 setup with mfi driver (PERC5i). 4GB RAM. I am currently running i386, and not amd64, due to various reasons. Kernel panic is at 0xC066C731, which from nm shows it's in mtx_lock_spin c066c7b4 T _mtx_lock_spin c066c85c T _mtx_unlock_sleep So this could mean that independent stress tests will not result in panic if there aren't enough concurrency to cause the problem. I don't have the exact IP address involved, but we experienced consistent panics in two heavily loaded mail servers (same hardware models, Dell Powereedge) runnning Postfix and FreeBSD 6.2. Suspecting an issue with the IP stack and smp I tried to set debug.mpsafenet=0 and the problems are gone. Of course I've lost some performance, but the systems have been solid for some weeks so far. What number is the PR with the details? Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel panic on PowerEdge 1950 under certain stress load
Benjie Chen wrote: Hi FreeBSD hackers and engineers, I am experiencing a kernel panic that comes on when my new PowerEdge 1950 FreeBSD 6.2 setup is under a certain stress load. I've emailed a few people on the list who have given me useful comments, some of which I am still following up. But I wanted to send a general cry for help to see if there are more knowledge out there about this problem. FreeBSD 6.2 on PowerEdge 1950, RAID1 setup with mfi driver (PERC5i). 4GB RAM. I am currently running i386, and not amd64, due to various reasons. I've ran exhaustively memory tests, disk tests, and network tests and cannot produce the kernel panic. I worked with Dell support to run memory test 1 DIMM at a time and cannot find any problem. With 1 DIMM at a time, I could still get the kernel panic under my work load. My work load is heavily hitting a web site running on the machine and requiring the web service to do MySQL requests. On the side, I am running a bunch of scripts that mostly read from the MySQL database but also write to it occasionally. Not memory intensive -- still have usually about 1GB free memory, but fairly disk intensive. I don't get disk errors. Anywhere from between 10 minutes to 4 or 5 hours into the test, I get the kernel panic. Again, still no disk errors. I turned off soft-update, still happens. Kernel panic is at 0xC066C731, which from nm shows it's in mtx_lock_spin c066c7b4 T _mtx_lock_spin c066c85c T _mtx_unlock_sleep So this could mean that independent stress tests will not result in panic if there aren't enough concurrency to cause the problem. There are a few other complaints about kernel panics at the same IP on the web (google 0xc066c731)... I was wondering if anyone had dealt with this before and if there are any work arounds? The IP is meaningless, it changes each time you compile your kernel. Unfortunately even knowing that it is in that symbol is nearly meaningless, because it doesn't provide enough information (only that your panic involved a spin mutex somehow). Please read the chapter on kernel debugging in the developers handbook and file a PR containing enough information for a developer to investigate the problem. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel panic on PowerEdge 1950 under certain stress load
On 24 Sep 2007, at 11:33, Kris Kennaway wrote: Borja Marcos wrote: I don't have the exact IP address involved, but we experienced consistent panics in two heavily loaded mail servers (same hardware models, Dell Powereedge) runnning Postfix and FreeBSD 6.2. Suspecting an issue with the IP stack and smp I tried to set debug.mpsafenet=0 and the problems are gone. Of course I've lost some performance, but the systems have been solid for some weeks so far. What number is the PR with the details? Sorry, I couldn't diagnose anything properly. When it happened the sysadmin didn't give me the panic details, and being production machines the main priority was to put them back into service as soon as possible. Would it be a good idea to file a PR with such fuzzy information? I don't think so, that's why I didn't do it. Of course I can do it if someone thinks it's worth. But unfortunately I cannot get more precise details. Borja. The thing he realised about the windows was this: because they had been converted into openable windows after they had first been designed to be impregnable, they were, in fact, much less secure than if they had been designed as openable windows in the first place. Douglas Adams, Mostly Harmless ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel panic on PowerEdge 1950 under certain stress load
Borja Marcos wrote: On 24 Sep 2007, at 11:33, Kris Kennaway wrote: Borja Marcos wrote: I don't have the exact IP address involved, but we experienced consistent panics in two heavily loaded mail servers (same hardware models, Dell Powereedge) runnning Postfix and FreeBSD 6.2. Suspecting an issue with the IP stack and smp I tried to set debug.mpsafenet=0 and the problems are gone. Of course I've lost some performance, but the systems have been solid for some weeks so far. What number is the PR with the details? Sorry, I couldn't diagnose anything properly. When it happened the sysadmin didn't give me the panic details, and being production machines the main priority was to put them back into service as soon as possible. Would it be a good idea to file a PR with such fuzzy information? I don't think so, that's why I didn't do it. Of course I can do it if someone thinks it's worth. But unfortunately I cannot get more precise details. No it isn't. You will need to do some more work to obtain this information, otherwise your bug will probably not be fixed. debug.mpsafenet=0 is no longer an option in 7.0, so you will have to deal with this sooner or later. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel panic on PowerEdge 1950 under certain stress load
Benjie Chen wrote: Kernel panic is at 0xC066C731, which from nm shows it's in mtx_lock_spin c066c7b4 T _mtx_lock_spin c066c85c T _mtx_unlock_sleep So this could mean that independent stress tests will not result in panic if there aren't enough concurrency to cause the problem. When you get a kernelbacktrace, see if it's the same as the one mentioned here: http://lists.freebsd.org/pipermail/freebsd-current/2007-September/076932.html signature.asc Description: OpenPGP digital signature
fsck of large volume with small memory
hi, all http://lists.freebsd.org/pipermail/freebsd-questions/2007-June/151686.html my problem # fsck /dev/aacd0s1f ** /dev/aacd0s1f (NO WRITE) ** Last Mounted on /usr ** Phase 1 - Check Blocks and Sizes fsck_ufs: cannot alloc 2378019004 bytes for inoinfo # cat /boot/loader.conf kern.maxdsiz=1073741824 # 1GB kern.dfldsiz=1073741824 # 1GB kern.maxssiz=134217728 # 128MB # uname -rms FreeBSD 6.2-STABLE amd64 # limits Resource limits (current): cputime infinity secs filesize infinity kB datasize 1048576 kB stacksize 131072 kB coredumpsize infinity kB memoryuseinfinity kB memorylocked infinity kB maxprocesses 5547 openfiles 11095 sbsize infinity bytes vmemoryuse infinity kB # dmesg|less Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-STABLE #4: Wed Sep 19 13:56:13 MSD 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/STONE Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Opteron(tm) Processor 248 (2191.66-MHz K8-class CPU) Origin = AuthenticAMD Id = 0xf5a Stepping = 10 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 AMD Features=0xe0500800SYSCALL,NX,MMX+,LM,3DNow!+,3DNow! real memory = 2147418112 (2047 MB) avail memory = 2066296832 (1970 MB) ACPI APIC Table: A M I OEMAPIC any solutions ? /Vladimir Ermakov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Intel D975XBX2 BTX halted
After experiencing overheating problems, I purchased a new CPU and motherboard (Intel D975XBX2) which has a built in Raid controller Marvell 88SE61xx I connected my existing FreeBSD-STABLE SATA drive to port 0. Upon boot, I receive the following error: int=000d err= efl=00030086 eip=1526 eax=0110 ebx= ecx= edx=95200110 esi=3684 edi=36ac ebp=4eac esp=4e9a cs=cf00 ds=9b00 es=cf00 fs=9941 gs=9ac0 ss=9b00 sc:eip=2e 0f 01 16 8d 07 0f 20-c0 40 0f 22 c0 b8 08 00 8e e8 67 66 65 89 0a 0f-20 c0 48 0f 22 c0 66 58 ss:esp=10 01 00 00 c0 9a 20 95-00 00 ff ff 00 00 ac 36 84 36 d4 4e 6c 32 00 01-00 00 00 40 25 00 00 00 BTX halted I have tried disabling the secondary SATA Controller, but it says no boot devices available. I have tried configuring my ATA/IDE Mode as Native (the default) and Legacy. I have tried configuring SATA as IDE, AHCI, and RAID I have tried S.M.A.R.T both enabled and disabled. Similar Posts: http://lists.freebsd.org/pipermail/freebsd-questions/2007-March/146146.html http://lists.freebsd.org/pipermail/freebsd-questions/2007-March/146252.html Thanks in advance, Kirby ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: linuxolator problem on i386
On Monday 24 September 2007, sam wrote: Hi # su hlds -c ktrace -i ./hlds_run -game cstrike +ip 0.0.0.0 +port 27015 +map de_dust -debug Auto detecting CPU Using Pentium II Optimised binary. Enabling debug mode Auto-restarting the server on crash Console initialized. scandir failed:/usr/home/hlds/1.6/./platform/SAVE Protocol version 47 Exe version 1.1.2.5/Stdio (cstrike) Exe build: 20:02:49 Oct 24 2006 (3651) STEAM Auth Server couldn't exec language.cfg Server IP address 0.0.0.0:27015 scandir failed:/usr/home/hlds/1.6/./platform/SAVE *** glibc detected *** ./hlds_i686: double free or corruption (!prev): 0x08da3738 *** === Backtrace: = /lib/libc.so.6[0x2811ac88] /lib/libc.so.6(cfree+0x90)[0x2811e230] /lib/libc.so.6(closedir+0x28)[0x2813ecf8] /lib/libc.so.6(scandir+0x14b)[0x2813f21b] /usr/home/hlds/1.6/filesystem_stdio_i386.so(findFileInDirCaseInsensitive__F PCc+0xe4)[0x28af41d8] /usr/home/hlds/1.6/filesystem_stdio_i386.so(FS_stat__17CFileSystem_StdioPCc P4stat+0x40)[0x28af861c] /usr/home/hlds/1.6/filesystem_stdio_i386.so(FastFindFileSize__15CBaseFileSy stemPCQ215CBaseFileSystem11CSearchPathPCc+0x17e)[0x28af572a] /usr/home/hlds/1.6/filesystem_stdio_i386.so(Size__15CBaseFileSystemPCc+0x5b )[0x28af557b] /usr/home/hlds/1.6/engine_i686.so(FS_FileSize+0x2a)[0x2828679e] === Memory map: 08048000-08054000 r-xp 0003a000 00:00 1931338 /usr/home/hlds/1.6/hlds_i686 08054000-0805b000 rw-p 0003a000 00:00 1931338 /usr/home/hlds/1.6/hlds_i686 0805b000-0805e000 rw-p 00d6 00:00 0 0805e000-08dbb000 rwxp 00d6 00:00 0 28054000-2806d000 r-xp 0001e000 00:00 1719480 /usr/compat/linux/lib/ld-2.5.so 2806d000-2806e000 r-xp 0001e000 00:00 1719480 /usr/compat/linux/lib/ld-2.5.so 2806e000-2806f000 rw-p 2000 00:00 0 2806f000-2807 rwxp 2000 00:00 0 28071000-28073000 r-xp 4000 00:00 1719493 /usr/compat/linux/lib/libdl-2.5.so 28073000-28074000 r-xp 4000 00:00 1719493 /usr/compat/linux/lib/libdl-2.5.so 28074000-28075000 rwxp 4000 00:00 1719493 /usr/compat/linux/lib/libdl-2.5.so 28075000-28076000 rwxp 1000 00:00 0 28076000-28088000 r-xp 0001e000 00:00 1719511 /usr/compat/linux/lib/libpthread-2.5.so 28088000-28089000 r-xp 0001e000 00:00 1719511 /usr/compat/linux/lib/libpthread-2.5.so 28089000-2808a000 rwxp 0001e000 00:00 1719511 /usr/compat/linuxAbort trap (core dumped) debug.cmds:1: Error in sourced command file: Previous frame inner to this frame (corrupt stack?) email debug.log to linux at valvesoftware.com http://lists.freebsd.org/mailman/listinfo/freebsd-emulation Wed Sep 12 20:27:04 SAMST 2007: Server restart in 10 seconds Wed Sep 12 20:27:06 SAMST 2007: Server Quit # === # uname -a FreeBSD damask 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Wed Sep 12 17:04:55 SAMST 2007 root at cs.udmvt.ru http://lists.freebsd.org/mailman/listinfo/freebsd-emulation:/usr/obj/usr/ src/sys/CS2 i386 # sysctl compat compat.linux.oss_version: 198144 compat.linux.osrelease: 2.6.16 compat.linux.osname: Linux # kldstat Id Refs AddressSize Name 1 14 0xc040 3e6ee0 kernel 21 0xc07e7000 69514acpi.ko 31 0xc3ddd000 7000 linprocfs.ko 42 0xc3de4000 21000linux.ko 51 0xc3e0e000 3000 linsysfs.ko # mount|grep linux linprocfs on /usr/compat/linux/proc (linprocfs, local) linsysfs on /usr/compat/linux/sys (linsysfs, local) # pkg_info | grep linux linux_base-fc6-6_3 Base set of packages needed in Linux mode (for i386/amd64) [private links to debug.log ktrace.out] please send me message after downloaded this files (for removing) /Vladimir Ermakov cross-posting: http://lists.freebsd.org/pipermail/freebsd-emulation/2007-September/003960. html I haven't tried it on i386 yet, but I know that this works on amd64 with linux 2.4 compat and linux_base-fc4 on FreeBSD 7. - Pieter ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel panic on PowerEdge 1950 under certain stress load
Ivan Voras wrote: Benjie Chen wrote: Kernel panic is at 0xC066C731, which from nm shows it's in mtx_lock_spin c066c7b4 T _mtx_lock_spin c066c85c T _mtx_unlock_sleep So this could mean that independent stress tests will not result in panic if there aren't enough concurrency to cause the problem. When you get a kernelbacktrace, see if it's the same as the one mentioned here: http://lists.freebsd.org/pipermail/freebsd-current/2007-September/076932.html Surely it cannot be since it involves a different function ;-) Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel panic on PowerEdge 1950 under certain stress load
On 24/09/2007, Kris Kennaway [EMAIL PROTECTED] wrote: Ivan Voras wrote: http://lists.freebsd.org/pipermail/freebsd-current/2007-September/076932.html Surely it cannot be since it involves a different function ;-) :) When all you have is a hammer... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel panic on PowerEdge 1950 under certain stress load
On 24/09/2007, Benjie Chen [EMAIL PROTECTED] wrote: Ivan and Kris, I will try to get a kernel trace -- it may not happen for awhile since I am not in the office and working remotely for awhile so it may not be easy to get a trace... but I will check. It's fairly easy: 1) add lines like the following in rc.conf: dumpdev=/dev/amrd0s1b dumpdir=/storage1/crashdumps (dumpdev is your swap partition, which must be larger than your RAM, dumpdir is where the crash dumps will be saved, also needs to be larger than RAM) 2) add these lines to sysctl.conf: debug.debugger_on_panic=0 debug.trace_on_panic=1 (These will cause the panic message and backtrace to be automatically recorded in the message buffer saved to the kernel crash dump. If not told otherwise, the machine will then reboot and at the next boot generate a crash dump in your dumpdir. When you get the kernel crash dump, run kgdb vmcore.0 /boot/kernel/kernel as root and then you can inspect the trace, core dump, etc. You don't need any special knowledge of (k)gdb for this. The one useful command to you may be bt - generate a backtrace). It looks like the problem reported by that link, and some of the links from there though... I'm trying to solve that one with Craig Rodrigues. So far it's been without success but we know where the problem is. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel D975XBX2 BTX halted
Hi, i have motherboard with integrated Marvell 88SE6141 controller. And i can't boot from any drives attached to this controller. This controller family is not yet supported. After experiencing overheating problems, I purchased a new CPU and motherboard (Intel D975XBX2) which has a built in Raid controller Marvell 88SE61xx I connected my existing FreeBSD-STABLE SATA drive to port 0. Upon boot, I receive the following error: -- WBR, Andrey V. Elsukov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Own Install CD with custom kernel
Hello Ulrich,
* Ulrich Spoerlein [EMAIL PROTECTED] [23-09-07 17:19]:
I'm using a Makefile to drive our release and package building and for
the releases I'm using an install.cfg, which gets created on the fly,
since the names of the kernels change now and then, here is the release
target
thx a lot for your really great answer, but I have some more short
questions. :)
Do you copy the release target to the Makefile in
/usr/src/release/Makefile or do you execute from another place?
rm -f ${TLR}/usr/src/release/.install.cfg
[...]
cd ${TRR}/R/ftp find -d . | cpio --quiet -dumpl ${TFR}
hm, cannot found the variables TLR and TRR anywhere defined. Can you
please give me some more information how your buildprocess looks?
And files/install.cfg contains the following
where should I store that file?
man release doesn't give here any information about it.
So basically, sysinstall is intructed to not install any kernel, but
after all distributions are extracted the following commands are run
command=/bin/sh -c cd /dist/${RELEASE}/kernels ./install.sh GENERIC
system
command=/bin/sh -c cd /dist/${RELEASE}/kernels ./install.sh SMP
system
where can you say sysinstall that it should run such commands after
the installation?
Best regards,
Matthias
--
Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning. --
Rich Cook
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fsck of large volume with small memory
On 24 Sep, sam wrote:
hi, all
http://lists.freebsd.org/pipermail/freebsd-questions/2007-June/151686.html
my problem
# fsck /dev/aacd0s1f
** /dev/aacd0s1f (NO WRITE)
** Last Mounted on /usr
** Phase 1 - Check Blocks and Sizes
fsck_ufs: cannot alloc 2378019004 bytes for inoinfo
I'd be willing to bet that one of the cylinder group blocks in your file
system got corrupted.
any solutions ?
The patch below should allow a manual fsck to run to completion. I'd
recommend running fsck -N and capturing its output. Then use the clri
command (either standalone or in fsdb) to zero out the uninitialized
inodes that are unmasked by setting cg_initediblk to its maximum
possible value based on the file system parameters.
Expect major file system lossage ...
I think this patch could be better, but this should get you going ...
Index: sbin/fsck_ffs/pass1.c
===
RCS file: /home/ncvs/src/sbin/fsck_ffs/pass1.c,v
retrieving revision 1.43
diff -u -r1.43 pass1.c
--- sbin/fsck_ffs/pass1.c 8 Oct 2004 20:44:47 - 1.43
+++ sbin/fsck_ffs/pass1.c 24 Sep 2007 23:15:22 -
@@ -93,9 +93,29 @@
inumber = c * sblock.fs_ipg;
setinodebuf(inumber);
getblk(cgblk, cgtod(sblock, c), sblock.fs_cgsize);
- if (sblock.fs_magic == FS_UFS2_MAGIC)
+ if (sblock.fs_magic == FS_UFS2_MAGIC) {
inosused = cgrp.cg_initediblk;
- else
+if (inosused 0 || inosused sblock.fs_ipg) {
+ pfatal(CG %d: PREPOSTEROUS NUMBER OF INODES %d
(cg_initediblk), ASSUMING %d (fs_ipg)\n,
+ c, inosused, sblock.fs_ipg);
+ /*
+* The cylinder group block is most likely
+* totally corrupted and will probably
+* fail the magic number check below as well.
+* Ignoring cg_initediblk and setting
+* inosused to sblock.fs_ipg will allow
+* a manual fsck to proceed further instead
+* of dying when it attempts to allocate
+* an insane amount of memory to store
+* the inode info for this cylinder group.
+* This may provide enough information
+* to allow the system administrator to
+* do a better job of patching the
+* filesystem with fsdb.
+*/
+ inosused = sblock.fs_ipg;
+ }
+ } else
inosused = sblock.fs_ipg;
if (got_siginfo) {
printf(%s: phase 1: cyl group %d of %d (%d%%)\n,
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fsck of large volume with small memory
On Mon, 2007-09-24 at 16:30 -0700, Don Lewis wrote: On 24 Sep, sam wrote: hi, all http://lists.freebsd.org/pipermail/freebsd-questions/2007-June/151686.html my problem # fsck /dev/aacd0s1f ** /dev/aacd0s1f (NO WRITE) ** Last Mounted on /usr ** Phase 1 - Check Blocks and Sizes fsck_ufs: cannot alloc 2378019004 bytes for inoinfo I'd be willing to bet that one of the cylinder group blocks in your file system got corrupted. any solutions ? The patch below should allow a manual fsck to run to completion. I'd recommend running fsck -N and capturing its output. Then use the clri command (either standalone or in fsdb) to zero out the uninitialized inodes that are unmasked by setting cg_initediblk to its maximum possible value based on the file system parameters. Expect major file system lossage ... You might also want to try ports/sysutils/ffsrecov2 before you run this fsck. It might allow you to recover data that would otherwise be lost. (Like, say, if there are directories hidden beneath the corrupt inode.) -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ http://www.zazzle.com/fmayhar* ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to use iic(4)
Ian Smith wrote this message on Sat, Sep 22, 2007 at 13:16 +1000: This drew a blank in -questions. I don't know where else to post it, so I'm hoping someone here might be able to spare me a clue. You should probably have posted this question to -hackers instead.. This is more low level hardware than networking... We're building a small board with two AVR Tiny MCUs chatting to each other over an opto-isolated I2C-compatible bus, hopefully at 400kbps. Hoping to use the iicbb(4) on lpbb(4) parallel port interface to talk with either of these MCUs for debugging, control and data acquisition. iic(4) says: === The iic character device driver provides generic i/o to any iicbus(4) instance. In order to control I2C devices, use /dev/iic? with the fol- lowing ioctls: Ioctl Description I2CSTART send start condition to the specified device (with 7-bit address) on the bus I2CSTOP send stop condition to the bus I2CRSTCARDreset the bus You may also use read/write routines, then I2C start/stop handshake is managed by the iicbus system. === Does the latter statement suggest that ordinary reads from or writes to /dev/iic? could be performed by redirection of say echo and read from a script? Or is the device only accessible by ioctl from eg a C program? No, as you need to select (via I2CSTART) the slave device you are talking w/ before you do a read or a write... Secondly, how does /dev/iic? come to exist? This 5.5-STABLE system seems to have all the requisite drivers, but there's no /dev/iic*: paqi% kldstat -v | egrep 'iic|lpbb' 29 iicbus/ic 30 iicbus/iic 31 bktr/iicbb 32 lpbb/iicbb 33 viapm/iicbb 34 pcf/iicbus 35 envctrl/iicbus 36 iicbb/iicbus 37 bti2c/iicbus 38 iicbus/iicsmb 86 iicsmb/smbus 121 0xc2456000 3000 lpbb.ko 247 ppbus/lpbb You need to have a device that connects between your i2c bus hardware and iicbb or iicbus... I'm not familar w/ lpbb, but I have used /dev/iic? w/ some HD capture card drivers I've written, and they are created when the device driver probes them... lpbb may need hints to get it to attach, or may need a properly functioning parallel port.. Also, iicbb(4) is said to be a master-only interface. I can work with that, but if anyone knows of any iicbus slave-mode code I'm all eyes .. That's even more complicated as you either need specialized hardware that will detect when your i2c address is on the bus, or you need to poll/interrupt on line changes, which could get a bit expensive... I have a command line iic program that I used to help debug my drivers.. The tool lets you start and then read/write from the device, and then stop the bus... I haven't committed it yet, because a few other developers want it under tools, and I don't like it there, as no one knows about most of the tools under there... Maybe if we had a man page that talked about the tools available there it'd be more attractive... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: linuxolator problem on i386
Pieter de Goeje wrote: On Monday 24 September 2007, sam wrote: # mount|grep linux linprocfs on /usr/compat/linux/proc (linprocfs, local) linsysfs on /usr/compat/linux/sys (linsysfs, local) # pkg_info | grep linux linux_base-fc6-6_3 Base set of packages needed in Linux mode (for i386/amd64) [private links to debug.log ktrace.out] please send me message after downloaded this files (for removing) /Vladimir Ermakov cross-posting: http://lists.freebsd.org/pipermail/freebsd-emulation/2007-September/003960. html I haven't tried it on i386 yet, but I know that this works on amd64 with linux 2.4 compat and linux_base-fc4 on FreeBSD 7. - Pieter yes, working but, this trouble in kernel new linux-software require linux 2.6 /Vladimir Ermakov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
