Re: Strange things going on with 4.8
On Sunday 10 August 2003 21:18, Samuel Kesterson wrote: Do you have more memory you can try? How about a power supply? Maybe you should even rule out the hard drive? I have FBSD 4.8-p1 running on 20+ servers that I can say with (near) 100% certainty take more of a beating in a day than your desktop, and they're all solid as rock. Potentially helpful information would include machine hardware configuration, third party drivers, etc. Basically anything that isn't part of the base. Do you get any errors in syslog from the ata subsystem (assuming you're using ata disks) or anything else for that matter? I have been wrong before, but this *really* sounds like a hardware problem. My hardware configuration: Epox 4BEA I845E FSB533 Motherboard Pentium 4 2GHz 512KB Tray 512MB DDR RAM Seagate Barracuda IV 80GB ST380021A, 7200rpm Lite On LTR-48125W 48/12/48 Toshiba 16/48 DVD ATAPI ATI Radeon 9000 64MB DDR/DVI 200MHz 2x NE 2000 PCI 10/100 Mbit Daniela ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Kernel core dump in recent 4.8-STABLE
Today my system coredumped (4.8-STABLE from Saturday), I believe it's somehow
X11 related:
X11 crashed first (signal 11). I was running it as root (I know I shouldn't).
I didn't think about it and restarted X11. While it was starting, I had a look
at the console, there was a bright white message: issignal.
This shows up at X11 startup.
Then the system coredumped.
Below is more information. Is this a serious problem?
Please help me, I'm an inexperienced programmer and I can't do this alone.
Daniela
# gdb -k kernel.debug vmcore.0
...
IdlePTD at phsyical address 0x005ba000
initial pcb at physical address 0x004d3100
panicstr: ufsdirhash_lookup: bad offset in hash array
panic messages:
---
panic: ufsdirhash_lookup: bad offset in hash array
syncing disks... 80 2 1
done
Uptime: 1d21h53m1s
/dev/vmmon: Module vmmon: unloaded
dumping to dev #ad/0x30001, offset 1048704
dump ata0: resetting devices .. done
511 ... 0
---
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
487 if (dumping++) {
(kgdb) where
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
#1 0xc021f00b in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316
#2 0xc021f449 in panic (
fmt=0xc0433ba0 ufsdirhash_lookup: bad offset in hash array)
at /usr/src/sys/kern/kern_shutdown.c:595
#3 0xc033b1d3 in ufsdirhash_lookup (ip=0xc262eb00,
name=0xd804c427
kufacts.cc.ukans.edu_ftp_pub_history_Europe_Medieval_aids_FF_4dbcef50,
namelen=73, offp=0xc262eb64, bpp=0xd8d2ecbc, prevoffp=0x0)
at /usr/src/sys/ufs/ufs/ufs_dirhash.c:361
#4 0xc033589d in ufs_lookup (ap=0xd8d2ed18)
at /usr/src/sys/ufs/ufs/ufs_lookup.c:212
#5 0xc033aa31 in ufs_vnoperate (ap=0xd8d2ed18)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2376
#6 0xc0248a8e in vfs_cache_lookup (ap=0xd8d2ed70) at vnode_if.h:77
#7 0xc033aa31 in ufs_vnoperate (ap=0xd8d2ed70)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2376
#8 0xc024b9f9 in lookup (ndp=0xd8d2eec8) at vnode_if.h:52
#9 0xc024b4f4 in namei (ndp=0xd8d2eec8) at /usr/src/sys/kern/vfs_lookup.c:153
#10 0xc0253f3f in vn_open (ndp=0xd8d2eec8, fmode=1, cmode=0)
at /usr/src/sys/kern/vfs_vnops.c:138
#11 0xc0250074 in open (p=0xd8b87f20, uap=0xd8d2ef80)
at /usr/src/sys/kern/vfs_syscalls.c:1029
#12 0xc03c25b5 in syscall2 (frame={tf_fs = 134676527, tf_es = 47,
---Type return to continue, or q return to quit---
tf_ds = -1078001617, tf_edi = 4, tf_esi = 686954328,
tf_ebp = -1077941708, tf_isp = -657264684, tf_ebx = 686871084,
tf_edx = 0, tf_ecx = 15, tf_eax = 5, tf_trapno = 12, tf_err = 2,
tf_eip = 686596376, tf_cs = 31, tf_eflags = 663, tf_esp = -1077941752,
tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1175
#13 0xc03b30a5 in Xint0x80_syscall ()
#14 0x28ee321f in ?? ()
#15 0x2920f154 in ?? ()
#16 0x292036ea in ?? ()
#17 0x291fbd7d in ?? ()
#18 0x291fbc8f in ?? ()
#19 0x29200061 in ?? ()
#20 0x281b434b in ?? ()
#21 0x281b05e4 in ?? ()
#22 0x291f9d97 in ?? ()
#23 0x804ccba in ?? ()
#24 0x804d9c0 in ?? ()
#25 0x804de1c in ?? ()
#26 0x804ec0e in ?? ()
#27 0x804b42e in ?? ()
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Server overloaded? Or is it a bug?
On Tuesday 03 June 2003 21:55, Erik Paulsen Skaalerud wrote: Did you try looking at its console? It probably have lots of pretty messages of whats going on.. Can't look at the console. It hangs completely. Hm. If its running X on the console, have you tried forcing it to a vty? (ie, alt+f2 or similar). If that doesnt work, I really dont know what to say but to reboot it and see if you are lucky, -maybe- dmesg -a have some errors in it from the failure. Or maybe /var/log/messages. It depends on what the failure was really. I just rebooted, but there are no messages. About one minute before the crash, when I wasn't able to run any more programs, I looked at the console (nothing special there), tried to login on ttyv6 (could enter the username, but no password prompt) and went back to X. There I tried to find out what has happened. The cd command was working as expected, but top and ps (for example) did just nothing. When I opened a new terminal session, it showed up, but I didn't get a prompt. I don't have much running, just KDE with about 10 programs on each of the 16 desktops, and a few background processes. This seems much, but I often have much more stuff running, and it is not even slow. It does respond when I ping it, but won't let me in over SSH. The processor doesn't sound busy, so I suspect that the scheduler has gone away, or there is some bug in the kernel, or some system table is too small. Hm. What kind of sound does a busy CPU make? :-) How do I find out what the problem is? (Never had any before.) Yeah, attach a console and find out whats going on. How can I do that? It doesn't respond to ctrl+alt+backspace and ctrl+alt+del, I can still move the mouse, but I can't click anything. See above (I known I shouldn't run X11 on a server.) You're right, the console of a server should not run X11 :( If you insist on running X11 on the console, maybe you should try to always keep an xterm open with console messages? (see /etc/syslog.conf) X11 doesn't run on the console, it runs on ttyvb. And it doesn't run always. I only need it when I have to see graphics (I'm a command-line freak :-)). FreeBSD has always managed the highest loads, even on normal PC hardware. Is it possible to bring the server back without rebooting? I would lose a lot of unsaved data if I had to reboot. I'm running 4.8-STABLE. When a server responds to ping, but ssh times out etc it often relates to hdd problems. Atleast in my experiences it has been so (dead disk). And if it is hdd problems, and FreeBSD couldnt get the disk to wake up again, you probably already have lost data. That could be the cause. One minute before the crash I could still enter shell builtin commands, but external commands did just nothing. Is it possible that the process table is full (I had more than 450 processes last time I ran top) or I ran out of memory (512M RAM + 1024M swap)? Well. Lets say that all the users use the same application. And all the users got the same bug with the application, wich made it forkbomb and consume large amounts of memory. 450 user-procs on the runaway could make this happen, but its very unlikely. FreeBSD is good at locking down things like this. But then again, if you run out of swap you're busted. I guess it's something with the processes. I'm pretty sure the kernel was still alive. The maximum number of processes is (maxusers * 20) + 18, right? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
