Panic on 6.0-RELEASE-p4 - Fatal trap 12
Hello list,
I've experienced a panic on a heavily loaded webserver running FreeBSD
6.0-RELEASE-p4, just some minutes ago. Just incase it's a new problem,
I'm posting it here.
# kgdb ./kernel.debug ./vmcore.0
[GDB will not be able to debug user-mode threads:
/usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
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:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0xac
fault code = supervisor write, page not present
instruction pointer = 0x20:0x806675ea
stack pointer = 0x28:0xe30d2c18
frame pointer = 0x28:0xe30d2c44
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 86 (swi4: clock sio)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 49d16h55m25s
Dumping 2047 MB (3 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 2046MB (523760 pages) 2030 2014 1998 1982 1966 1950 1934 1918
1902 1886 1870 1854 1838 1822 1806 1790 1774 1758 1742 1726 1710 1694
1678 1662 1646 1630 1614 1598 1582 1566 1550 1534 1518 1502 1486 1470
1454 1438 1422 1406 1390 1374 1358 1342 1326 1310 1294 1278 1262 1246
1230 1214 1198 1182 1166 1150 1134 1118 1102 1086 1070 1054 1038 1022
1006 990 974 958 942 926 910 894 878 862 846 830 814 798 782 766 750 734
718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478 462 446
430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158
142 126 110 94 78 62 46 30 14 ... ok
chunk 2: 1MB (128 pages)
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) backtrace
#0 doadump () at pcpu.h:165
#1 0x805aef82 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399
#2 0x805af374 in panic (fmt=0x80777163 "%s") at
/usr/src/sys/kern/kern_shutdown.c:555
#3 0x8075107c in trap_fatal (frame=0xe30d2bd8, eva=0) at
/usr/src/sys/i386/i386/trap.c:831
#4 0x80750d2f in trap_pfault (frame=0xe30d2bd8, usermode=0, eva=172) at
/usr/src/sys/i386/i386/trap.c:742
#5 0x807508bd in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = -2130444248, tf_edi = 0, tf_esi =
4, tf_ebp = -485675964, tf_isp = -485676028, tf_ebx = -1970586144,
tf_edx = -2130424216, tf_ecx = -2091403008, tf_eax = 4, tf_trapno = 12,
tf_err = 2, tf_eip = -2140768790, tf_cs = 32, tf_eflags = 66195, tf_esp
= -1970586144, tf_ss = 0})
at /usr/src/sys/i386/i386/trap.c:432
#6 0x8073a2fa in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0x806675ea in tcp_timer_2msl_tw (reuse=0) at atomic.h:149
#8 0x80666f7c in tcp_slowtimo () at /usr/src/sys/netinet/tcp_timer.c:136
#9 0x805f3589 in pfslowtimo (arg=0x0) at
/usr/src/sys/kern/uipc_domain.c:475
#10 0x805bec76 in softclock (dummy=0x0) at
/usr/src/sys/kern/kern_timeout.c:290
#11 0x80592ea8 in ithread_loop (arg=0x83522e80) at
/usr/src/sys/kern/kern_intr.c:547
#12 0x80591ae0 in fork_exit (callout=0x80592cf0 , arg=0x4,
frame=0x4) at /usr/src/sys/kern/kern_fork.c:789
#13 0x8073a35c in fork_trampoline () at
/usr/src/sys/i386/i386/exception.s:208
I've got a dozen more webservers (most on -p5, tho) that have been up
for a couple of months now, and none experienced this. All this server
does is running apache and ssh. The /tmp partition is mounted as md, if
it matters.
If this seems interesting and more information is needed, let me know.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Keyboard 'fails' in ddb on HP Proliant DL380 under 6.1-RC1
Hi All, We've recently started using HP Proliant DL360's / 380's - and we're also moving our new machines to FreeBSD 6.1 I've found a problem with ddb - no matter what I do, I can't get the keyboard on the server to work, when it's dropped into ddb. I've tried HP's iLO management (virtual console / keyboard) - and, thinking maybe that was messing up - plugging in a real keyboard and monitor into the server, and avoiding iLO. No matter how you end up in ddb (through a console command, a real 'panic', NMI, 'break' or Ctrl-Alt-Esc) - once you're there - the keyboard is dead. I've checked the manpage for 'atkbd' - but can't see anything obvious. These machines running 5.3/4 work fine - it's just under 6.x the problem appears. You can find a verbose boot output at: http://www.tdx.com/verbose_6.1rc1.txt Anyone got any suggestions? - We've also found a potential problem with the ciss driver, but I can't even start to look at that until ddb is useable :( Cheers, -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Keyboard 'fails' in ddb on HP Proliant DL380 under 6.1-RC1
Karl Pielorz wrote: I've found a problem with ddb - no matter what I do, I can't get the keyboard on the server to work, when it's dropped into ddb. Try to boot in safe mode: http://docs.freebsd.org/cgi/mid.cgi?4437E1AD.7000303 -- 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: Keyboard 'fails' in ddb on HP Proliant DL380 under 6.1-RC1
--On 27 April 2006 16:34 +0400 "Andrey V. Elsukov" <[EMAIL PROTECTED]> wrote: Karl Pielorz wrote: I've found a problem with ddb - no matter what I do, I can't get the keyboard on the server to work, when it's dropped into ddb. Try to boot in safe mode: http://docs.freebsd.org/cgi/mid.cgi?4437E1AD.7000303 Yup, pfft - no idea how I managed to miss finding that post :( - It wasn't for want of looking... Oh well, one problem kind of down, one to go :) Thanks, -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fwd: Can kldload trigger pci bus rescan?
It would be cool if pccard and usb also reprobed when kldload ran. The usb case is slightly more complex --- having (say) uscanner claim something that ugen is currently claiming. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Jail Quotas - quota.user hard link
On Thu, 27 Apr 2006, Michael R. Wayne wrote: On Wed, Apr 26, 2006 at 06:23:59PM -0400, Charles Sprickman wrote: I have a question about using quotas in a jail with FreeBSD 6.x. So far I have had no problems on a test box with setting quotas from the host using a numeric UID (ie: edquota -u 2 where UID 2 is a user that only exists in a jail). That seems to "just work". Just a heads up: quotas in jails on FreeBSD 6 are pretty broken. I'll include some workarounds. Basic operation can be done by specifying a filename, available in the jail, which contains the quotas. So, on the base system, /etc/fstab contains: /dev/twed0s2f /usr/jails/foo.bar.com ufs rw,userquota=/usr/jails/foo.bar.com/usr/quotas/shell.root 2 2 and on the foo.bar.com jail, /etc/fstab contains: /dev/twed0s2f / ufs rw,userquota=/usr/quotas/shell.root,noauto 2 2 I'm loosely under the impression that it should be possible to both query and manage quota data on live file systems without ever touching the quota backing file (which is an error-prone mechanism because live quota data is cached in the kernel without constantly refering back to the quota file, so writing to the file runs into cache coherency problems). In particular, you can set security.bsd.unprivileged_get_quota to 1 to allow a user to query another user's quota using the syscall interface. It could be that we don't allow these syscalls to work from within a jail though, or that they look at /etc/fstab to decide if they should use the syscall, which should be fixable. Robert N M Watson Now the problems begin. You either do chmod a+r /usr/quotas/shell.root which permits everyone on the machine to read all quotas (both quota and repquota) or chmod o-r /usr/quotas/shell.root which permits ONLY root to read any quotas. Normal users can not see their own quotas (I filed a PR on this quite some time back, nobody seems interested). This seems to be new breakage since 4.x Also, if you edquota from within the jail, it does not really take effect. You can stick an hourly cron script on the base system containing quotaoff -a quotacheck -a quotaon -a which will "fixup" the mess. Alternately, you can only use edquota from the base system which seems to mostly work. ISTR that there was something else that was odd but I'm sure somebody else will jump in and mention it. /\/\ \/\/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Keyboard 'fails' in ddb on HP Proliant DL380 under 6.1-RC1
Karl, What Generation of DL380 do you have. I am currently Running 6.0 and 6.1-RC on DL380 G3's and G4's as well as the DL360 G3 & G4 . I have not run in to that issue before and I would suspect bad hardware . -- Mark Saad [EMAIL PROTECTED] DataPipe Support Team 1.201.792.4847 (international) 1.888.749.5821 (toll free) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel 6300ESB SATA - Now Tyan B5350G20S2H-LC
On Wednesday 26 April 2006 21:36, Alain Hebert wrote: > Well, > > Good and bad news... > > 6.1-RC works to install (thanks Soren) > > But BTX halt on boot: > > - > int=000d err= efl=00030002 eip=10ce > eax=000c0002 ebx= ecx=0005 edx=0100 > esi=00b6 edi=03f0 ebp=3778 esp=3754 > cs=c800 ds=c800 es=1400fs= gs=9880 ss=9880 > cs:eip=2e 0f 01 1e 1d 11 2e 0f-01 16 23 11 0f 20 c0 66 > 25 ff ff ff 7f 0c 01 0f-22 c0 eb 00 0f 01 e0 a8 > ss:esp=46 02 09 0e 00 00 00 00-b6 00 80 98 88 36 f0 03 > b6 00 78 37 72 37 00 00-00 01 05 00 00 00 00 00 > BTX halted It's in your BIOS (cs=0xc800) 2E0F011E1D11 lidt [cs:0x111d] 0006 2E0F01162311 lgdt [cs:0x1123] 000C 0F20C0mov eax,cr0 000F 6625FF7F and eax,0x7fff 0015 0C01 or al,0x1 0017 0F22C0mov cr0,eax 001A EB00 jmp short 0x1c 001C 0F01E0smsw ax Your BIOS is trying to enter protected mode. Try turning off support for DMA in your BIOS. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel 6300ESB SATA - Now Tyan B5350G20S2H-LC
Hi, Yeap, I fired up my MS-DOS 6.22 with debug.exe this morning. Its the M8110 SO-DIMM RAID card ROM that does it. And there is no control for that in the BIOS or Adaptec Menu. That motherboard also has a ATA_I6300ESB_R1 RAID 1 card ... on which BTX works but 6.1-RC dont recognize the MetaData. So I'm working around the issue while I wait for Tyan to tell me how to upgrade the M8110 ROM. FYI: I dont see the lidt / ligt opcode in the new version of that ROM. I'll let you guys know. John Baldwin wrote: On Wednesday 26 April 2006 21:36, Alain Hebert wrote: Well, Good and bad news... 6.1-RC works to install (thanks Soren) But BTX halt on boot: - int=000d err= efl=00030002 eip=10ce eax=000c0002 ebx= ecx=0005 edx=0100 esi=00b6 edi=03f0 ebp=3778 esp=3754 cs=c800 ds=c800 es=1400fs= gs=9880 ss=9880 cs:eip=2e 0f 01 1e 1d 11 2e 0f-01 16 23 11 0f 20 c0 66 25 ff ff ff 7f 0c 01 0f-22 c0 eb 00 0f 01 e0 a8 ss:esp=46 02 09 0e 00 00 00 00-b6 00 80 98 88 36 f0 03 b6 00 78 37 72 37 00 00-00 01 05 00 00 00 00 00 BTX halted It's in your BIOS (cs=0xc800) 2E0F011E1D11 lidt [cs:0x111d]/2 0006 2E0F01162311 lgdt [cs:0x1123] 000C 0F20C0mov eax,cr0 000F 6625FF7F and eax,0x7fff 0015 0C01 or al,0x1 0017 0F22C0mov cr0,eax 001A EB00 jmp short 0x1c 001C 0F01E0smsw ax Your BIOS is trying to enter protected mode. Try turning off support for DMA in your BIOS. -- Alain Hebert[EMAIL PROTECTED] PubNIX Inc. P.O. Box 175 Beaconsfield, Quebec H9W 5T7 tel 514-990-5911 http://www.pubnix.netfax 514-990-9443 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can kldload trigger pci bus rescan?
In message: <[EMAIL PROTECTED]> "Zaphod Beeblebrox" <[EMAIL PROTECTED]> writes: : It would be cool if pccard and usb also reprobed when kldload ran. The usb : case is slightly more complex --- having (say) uscanner claim something that : ugen is currently claiming. PC Card has done so for years, OLDCARD and NEWCARD. In fact, you can even load and unload the bridge driver (cbb today, pcic in yesteryear) and the pccard bus driver. pccard works very hard to make sure that these things work. usb does also, but not in a manner that's useful. It does work with usb for simple devices when ugen isn't loaded into the kernel. However, the brain dead way that usb dollops out subdevices makes fixing it to work like rest of the system difficult... The port from NetBSD didn't take the time to make the device model match FreeBSD, but rather just shoe-horned it into the system. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Keyboard 'fails' in ddb on HP Proliant DL380 under 6.1-RC1
On Thursday 27 April 2006 13:26, Mark Saad wrote: > Karl, > What Generation of DL380 do you have. I am currently Running 6.0 and > 6.1-RC on DL380 G3's and G4's as well as the DL360 G3 & G4 . I have not > run in to that issue before and I would suspect bad hardware . You have to have 'device kbdmux' enabled to hit the issue. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
