fsck and dump freeze freebsd. any ideas?
The smartctl tests on the three drives came back saying they were checked 100% without error; bad sectors have always caused an error and an aborted scan at the point of trouble for me in the past. I 'thought' I recalled seeing a panic along the lines of ffs_free or something related to free blocks or something at one point; maybe that was an error with fsck on the live system when manually ran. I will try to reproduce. Otherwise I do not know that fsck crashes; the entire system locks. I will see if I can reproduce the problem as a panic. There were some errors fsck seems to think it cleaned. A couple still exist indicating wrong counts about '12 should be 4' or '4 should be 0' type stuff. One error had a ridiculously large seven digit or so number that fsck said should be reduced. I had made a many terabyte file with a dd write to the end of a file of the largest size it would let me create and have since deleted the file; maybe that was what the reference was to. After fixing some errors, the fsck still causes a freeze and at what seems to be about the same point. The filesystem was unmounted for the dump and fsck has been attempted both mounted and unmounted. The filesystem has (ufs, NFS exported, local, soft-updates) reported for features by mount under normal operation. The freeze with dump did occur during a snapshot creation, which I found I cannot kill with a -9 (kill attempted minutes before the crash which still would not stop the creation). The powerdown question is more for how to handle an unsafe powerdown/crash on an active system. If I need to read from a partition, would read only leave it completely clean? Is there a way to operate on a file system which is treated as more of a ramdisk of changes and keeps the real partition unmodified (giving results like Faronics deepfreeze software or qemu disks in snapshot mode)? Would a zfs mirror configuration handle the unexpected crash/powerdown? Would it just report and fix the corruption, mention what files/structures weror impacted, offer restore of that data from a recent snapshot, or just say it is time to restore from a backup? Thanks again for the feedback, Ed Sutton ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
How to get SystemMemorySize?
Something like the following should use the power of sysctl. physmem and usermem in place of realmem may be of use too. Just wish I knew proper values nad logic to tweak kern.ipc.shmmax and similar paramaters. int realmem; char* realmem_mib_name = hw.realmem; return(sysctlbyname(usermem_mib_name, realmem, len, 0, 0)) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
SATA DVD issues
For the encrypted DVDs, have you set a region for the drive to match? How are you accessing them? Further hardware information may help (people better at this than I) identify issues; what SATA controller connects the drive. Last I checked, my promise controller cards seem to have incomplete drivers for what is needed to support optical drives unless I misunderstood the code. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
kernel panic on SATA drive
The FreeBSD Developers' Handbook describes how to get panic information (and dig out further details). http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html#KERNELDEBUG-OBTAIN Was there any output before ad7: FAILURE - device detached? Losing the drive in the bios makes me think hardware, but I'd check for any firmware problems/updates if they exist. I have not tried yet, but FreeBSD8 is supposed to finally handle the anxiety of losing a drive. http://freebsdfoundation.org/press/2008Dec-newsletter.shtml#Project1 I would try smartctl from ports; run a long scan and read the full output to see if it passes or if you get a response like: # 1 Extended offlineCompleted: read failure 20% 32490 308342849 Also look above that output to see if there any metioned 'Error ## occured at disk power-on lifetime' type of messages. to scan, run: smartctl -t long /dev/ad7 after the scan, read output with: smartctl -a long /dev/ad7 What motherboard is it? GeForce 8200 sounds like a graphics chipset to me. For hardware analysis, try to isolate it to a particular drive (sounds like it is only the seagate), cable (data or power), motherboard sata port. When the drive is not recognized, does a coldboot redetect it? Does the drive start any audible clicking? What model of drive is it? Make sure the drive is dusted off, increase the cooling, and try again; I have a drive that flakes out if the three speed antec fan in front of it is only on low but stabilizes when kept cooler; its a great hint to me that the drive is near life's end. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Xorg 7.4 issue
The keyboard works in some apps but not others? What video driver (and have you tried vesa if not using it to see if the problem can still be reproduced)? All x11 related drivers were rebuilt too? Output from the xorg logfile and your xorg.conf may be helpful. Maybe there is other relevant output to the console that X is launched from. Maybe a different problem, but I had trouble with keyboard input not appearing (and all of the X screen freezing; no blinking clock). It would come back with touching the mouse, and freezing was also caused by using the mouse. The trouble appeared back when AllowEmptyInput was discussed in the ports UPDATING file, but that no longer seems to work right (nor does DontZap) in my xorg.conf. I found things worked right by stopping hald before launching X. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
fsck and dump freeze freebsd. any ideas?
After one of the last crashes, the system would lock up a short time after rebooting. I found the problem caused by background fsck locking up the system. I took the partition out of the startup check for now. I 'think' I was installing a port during the last crash, but it has been a while. I performed a fsck and a dump (to /dev/null) confirming that both do crash the freebsd 7.2 and 6.2 (which I booted off of a separate drive). A tar to /dev/null did run successfully, but I recall reading that that is not a recommended way to backup/move a filesystem. The /usr partition where it causes trouble is in a raid5 geom_vinum three drive array. I did not yet have the array rebuild the parity nor do I know if there is any advantage/disadvantage in doing so (for this problem). I ran a long test on the drives using smartctl (which is a safer surface check than dd because 1 bad sector on my promise controller will cause a panic; I have an unrelated drive with a corrupted sector if the promise controller dirver has an interested maintainer.) When running fsck, it is somewhere within phase 1 when it crashes. I ran a truss run of fsck with -aedD and snapped a photo of my screen when it crashed which I can type up if it is of any use. At the time of freebsd freezing, the hard drive activity light goes from a faint flicker to on solid for about a second and then goes out. The system is completely unresponsive where it locks showing no sign of activity that I have been able to notice. I imagine the recommendation is start over, but before I do (and likely just try a tar backup/restore), are there any other suggestions and questions before I blow away the problem? It would be nice for freebsd users to not be able to run into such a problem. As a final question, is there any safe way to crash freebsd (or pull system power) without a risk of filesystem corruption? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
need help: crashing appears to be caused by/within console screen saver
I do not know where I should ask for help but I have core files from July 24, 23, 21 (x2), 19, 16 (x2) and May 17. All of the July crashes appear similar. The May crash was unrelated but shows that things were relatively stable until the first of these glitches. I am currently using the nvidia driver version 180.60 from ports on FreeBSD 7.2-RELEASE #0. The crashes typically take place when running through port rebuilds and upgrades, which I often do from the 3rd terminal. It usually occurs when I am away, but I just saw it where it looked like it was going to load the terminal screen saver and the screen just sat blank for maybe 10 seconds and then the system was restarting. I have since unloaded logo_saver.ko but would still like to resolve the source of the crashes if possible. Any suggestions where I should go from here and what other information would be helpful? At the end I copied a kgdb with a backtrace; It is what lead me to see that it crashed each time as the screen saver was activating (or so it now seems likely). Thanks again, Edward Sutton # kgdb kernel.debug /var/crash/vmcore.22 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... Unread portion of the kernel message buffer: panic: pmap_mapdev: Couldn't alloc kernel virtual memory cpuid = 0 Uptime: 11h49m19s Physical memory: 2031 MB Dumping 233 MB: 218 202 186 170 154 138 122 106 90 74 58 42 26 10 Reading symbols from /boot/kernel/splash_bmp.ko...Reading symbols from /boot/kernel/splash_bmp.ko.symbols...done. done. Loaded symbols for /boot/kernel/splash_bmp.ko Reading symbols from /boot/kernel/vesa.ko...Reading symbols from /boot/kernel/vesa.ko.symbols...done. done. Loaded symbols for /boot/kernel/vesa.ko Reading symbols from /boot/kernel/geom_vinum.ko...Reading symbols from /boot/kernel/geom_vinum.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_vinum.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/snd_ich.ko...Reading symbols from /boot/kernel/snd_ich.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_ich.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/aio.ko...Reading symbols from /boot/kernel/aio.ko.symbols...done. done. Loaded symbols for /boot/kernel/aio.ko Reading symbols from /boot/kernel/sem.ko...Reading symbols from /boot/kernel/sem.ko.symbols...done. done. Loaded symbols for /boot/kernel/sem.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/modules/kqemu.ko...done. Loaded symbols for /boot/modules/kqemu.ko Reading symbols from /boot/modules/ltmdm.ko...done. Loaded symbols for /boot/modules/ltmdm.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/logo_saver.ko...Reading symbols from /boot/kernel/logo_saver.ko.symbols...done. done. Loaded symbols for /boot/kernel/logo_saver.ko Reading symbols from /usr/local/modules/rtc.ko...done. Loaded symbols for /usr/local/modules/rtc.ko #0 doadump () at pcpu.h:196 196 __asm __volatile(movl %%fs:0,%0 : =r (td)); (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc0590dbf in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc0591084 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc07ffc54 in pmap_mapdev_attr (pa=3489660928, size=268435456, mode=0) at /usr/src/sys/i386/i386/pmap.c:4349 #4 0xc07ffcfe in pmap_mapdev (pa=3489660928, size=268435456) at /usr/src/sys/i386/i386/pmap.c:4366 #5 0xc09b51d5 in vesa_set_mode (adp=0xc08e5620, mode=259) at /usr/src/sys/modules/vesa/../../i386/isa/vesa.c:835 #6 0xc642ea58 in logo_saver (adp=0xc08e5620, blank=1) at /usr/src/sys/modules/syscons/logo/../../../dev/syscons/logo/logo_saver.c:117 #7 0xc04909f6 in splash (adp=0xc08e5620, on=1) at /usr/src/sys/dev/fb/splash.c:211 #8 0xc04da60c in scsplash_saver (sc=0xc08f2960, show=1) at /usr/src/sys/dev/syscons/syscons.c:1957 #9 0xc04dc72e in scrn_timer (arg=0xc08f2960) at /usr/src/sys/dev/syscons/syscons.c:1767 #10 0xc05a27af in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:274 #11
