RE: Panic vm_page_alloc(sendfile)
> >On 25-May-01 Tamiji Homma wrote: > > John, > > > > Thank you for quick patch. But I hate to report "The patch didn't work." > > You need another patch to try ;-) > It sort of worked. :) It got farther along. :) Please try the updated > sendfile.patch. Thanks. The second patch worked! You are so fast! ;-) Thanks. Tammy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Panic vm_page_alloc(sendfile)
John,
Thank you for quick patch. But I hate to report "The patch didn't work."
You need another patch to try ;-)
Here is trace back. I omitted details (I still do hand copy)
If you need exact trace back, I'll have to setup serial port.
panic: mutex vm not owned at ../../vm/vm_page.h:320
Debugger("panic")
Stop at Debugger+0x44: pushl %ebx
db> trace
Debugger
panic
_mtx_assert
vm_page_unwire
sf_buf_free
sbdrop
tcp_input
ip_input
ipintr
swi_net
ithread_loop
fork_exit
fork_trampoline
Tammy
From: John Baldwin <[EMAIL PROTECTED]>
Subject: RE: Panic vm_page_alloc(sendfile)
Date: Fri, 25 May 2001 10:47:51 -0700 (PDT)
Message-ID: <[EMAIL PROTECTED]>
jhb>
jhb> On 25-May-01 Tamiji Homma wrote:
jhb> > Hi,
jhb> >
jhb> > I noticed this panic for last few days on my -current
jhb> > sandbox laptop.
jhb> >
jhb> > When I do FTP get file from the machine running
jhb> > -current causes panic like below (hand copied).
jhb> >
jhb> > The machine running ftpd panics not FTP client side.
jhb> > I have not tried FTP put yet... It may panic at FTP
jhb> > client side as well.
jhb> >
jhb> > My last cvsup was around 22:00 PDT on May 24 2001.
jhb> >
jhb> > panic: mutex vm not owned at ../../vm/vm_page.c:755
jhb> > Debugger("panic")
jhb> > db> trace
jhb> > Debugger(c038865b) at Debugger+0x44
jhb> > panic(c0387828,c03a0554,c03a1eaf,2f3,0) at panic+0x70
jhb> > _mtx_assert(c045ca20,1,c03a1eaf,2f3) at _mtx_assert+0x49
jhb> > vm_page_alloc(c8bcc9c0,0,0,c8b04b9c,c8b04a80) at vm_page_alloc+0x22
jhb> > sendfile(c8b04a80,c8b43f80,0,0,381508) at sendfile+0x31e
jhb> > syscall(2f,2f,2f,381508,0) at syscall+0x689
jhb> > syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
jhb> >
jhb> > PS: I am not subscribed to -current but subscribed to
jhb> > current-digest so if it is already reported/fixed, sorry...
jhb>
jhb> Cool, thanks for the bug report. Please try the patch at
jhb> http://www.FreeBSD.org/~jhb/patches/sendfile.patch.
jhb>
jhb> --
jhb>
jhb> John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
jhb> PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
jhb> "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Panic vm_page_alloc(sendfile)
Hi,
I noticed this panic for last few days on my -current
sandbox laptop.
When I do FTP get file from the machine running
-current causes panic like below (hand copied).
The machine running ftpd panics not FTP client side.
I have not tried FTP put yet... It may panic at FTP
client side as well.
My last cvsup was around 22:00 PDT on May 24 2001.
panic: mutex vm not owned at ../../vm/vm_page.c:755
Debugger("panic")
db> trace
Debugger(c038865b) at Debugger+0x44
panic(c0387828,c03a0554,c03a1eaf,2f3,0) at panic+0x70
_mtx_assert(c045ca20,1,c03a1eaf,2f3) at _mtx_assert+0x49
vm_page_alloc(c8bcc9c0,0,0,c8b04b9c,c8b04a80) at vm_page_alloc+0x22
sendfile(c8b04a80,c8b43f80,0,0,381508) at sendfile+0x31e
syscall(2f,2f,2f,381508,0) at syscall+0x689
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
PS: I am not subscribed to -current but subscribed to
current-digest so if it is already reported/fixed, sorry...
Tammy
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: vm_page_remove panic
>What's your filesystem configuration? Do a 'df'. Are any of the >filesystems non-standard? /usr/src on /dev/ad0s2f /usr/obj on /dev/ad2f /usr/home/ncvs on /dev/ad0s2f I think that swap is 256MB. Thanks Tammy Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ad0s2a 63503379732045065%/ /dev/ad0s2f 3821072 2736001 77938678%/usr /dev/ad0s2e127023 9585 107277 8%/var procfs 440 100%/proc /dev/ad2a 31743152711393352%/w/root /dev/ad2e 127023 443 116419 0%/w/var /dev/ad2f10495674 4293383 536263844%/w/usr /dev/ad0s2a on / (ufs, NFS exported, local, soft-updates, writes: sync 5 async 1709, reads: sync 639 async 25) /dev/ad0s2f on /usr (ufs, NFS exported, local, soft-updates, writes: sync 6 async 13365, reads: sync 50750 async 310) /dev/ad0s2e on /var (ufs, local, soft-updates, writes: sync 75 async 946, reads: sync 422 async 4) procfs on /proc (procfs, local) /dev/ad2a on /w/root (ufs, local, soft-updates, writes: sync 2 async 7, reads: sync 48 async 0) /dev/ad2e on /w/var (ufs, local, soft-updates, writes: sync 2 async 4, reads: sync 47 async 0) /dev/ad2f on /w/usr (ufs, NFS exported, local, soft-updates, writes: sync 2 async 15065, reads: sync 42576 async 7) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vm_page_remove panic
Matt>What's your filesystem configuration? Do a 'df'. Are any of the Matt>filesystems non-standard? non-standard? You mean block size, etc? I don't have access to that machine right now but it should be what you call standard ;-) I'll get back to you later today. No special newfs flags for all filesystems. It's just plain sysinstall created filesystems. By the way, all filesystems including / are softupdates enabled. Thanks Tammy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
vm_page_remove panic
Hi,
I have been seeing vm_page_remove panic three times since
last week. During make world once, cvsup twice. It seems
reproducible.
Any clue?
Thanks
Tammy
snoopy# uname -a
FreeBSD snoopy.pochi.com 4.0-CURRENT FreeBSD 4.0-CURRENT #94: Sun Dec 19 10:40:05 PST
1999 [EMAIL PROTECTED]:/usr/src/sys/compile/SNOOPY i386
snoopy# gdb -k /usr/src/sys/compile/SNOOPY/kernel.debug /var/crash/vmcore.1
GNU gdb 4.18
Copyright 1998 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-unknown-freebsd"...
IdlePTD 3440640
initial pcb at 2c8300
panicstr: from debugger
panic messages:
---
panic: vm_page_remove(): page not found in hash
panic: from debugger
Uptime: 8h7m54s
dumping to dev #ad/0x30001, offset 393216
dump ata0: resetting devices .. done
64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36
35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6
5 4 3 2 1
---
#0 boot (howto=260) at ../../kern/kern_shutdown.c:303
303 dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0 boot (howto=260) at ../../kern/kern_shutdown.c:303
#1 0xc015b4ed in panic (fmt=0xc0275294 "from debugger")
at ../../kern/kern_shutdown.c:553
#2 0xc012faa5 in db_panic (addr=-1071395625, have_addr=0, count=-1,
modif=0xc62e8b50 "") at ../../ddb/db_command.c:433
#3 0xc012fa45 in db_command (last_cmdp=0xc02a565c, cmd_table=0xc02a54bc,
aux_cmd_tablep=0xc02c46e4) at ../../ddb/db_command.c:333
#4 0xc012fb0a in db_command_loop () at ../../ddb/db_command.c:455
#5 0xc0131b9b in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#6 0xc023ca7b in kdb_trap (type=3, code=0, regs=0xc62e8c54)
at ../../i386/i386/db_interface.c:157
#7 0xc024b3d0 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = 1074780922, tf_esi = 256, tf_ebp = -970027876,
tf_isp = -970027904, tf_ebx = -1071073184, tf_edx = 1073741824,
tf_ecx = 0, tf_eax = 18, tf_trapno = 3, tf_err = 0,
tf_eip = -1071395625, tf_cs = 8, tf_eflags = 582, tf_esp = -1071030625,
tf_ss = -1071137789}) at ../../i386/i386/trap.c:533
#8 0xc023ccd7 in Debugger (msg=0xc027bc03 "panic") at machine/cpufunc.h:64
#9 0xc015b4e4 in panic (
fmt=0xc028b860 "vm_page_remove(): page not found in hash")
at ../../kern/kern_shutdown.c:551
#10 0xc020cb53 in vm_page_remove (m=0xc04d05b0) at ../../vm/vm_page.c:448
#11 0xc020d194 in vm_page_free_toq (m=0xc04d05b0) at ../../vm/vm_page.c:1080
#12 0xc020cedb in vm_page_alloc (object=0xc6336900, pindex=3, page_req=0)
---Type to continue, or q to quit---
at ../../vm/vm_page.h:504
#13 0xc017e588 in allocbuf (bp=0xc1c90900, size=8192)
at ../../kern/vfs_bio.c:2375
#14 0xc017e17e in getblk (vp=0xc639d640, blkno=1, size=8192, slpflag=0,
slptimeo=0) at ../../kern/vfs_bio.c:2153
#15 0xc01f3554 in ffs_balloc (ap=0xc62e8e68) at ../../ufs/ffs/ffs_balloc.c:170
#16 0xc01fc1dd in ffs_write (ap=0xc62e8ea0) at vnode_if.h:1035
#17 0xc018cd4e in vn_write (fp=0xc09aa100, uio=0xc62e8eec, cred=0xc08fbd80,
flags=0, p=0xc5dca700) at vnode_if.h:363
#18 0xc0168515 in dofilewrite (p=0xc5dca700, fp=0xc09aa100, fd=9,
buf=0x843400c, nbyte=7461, offset=-1, flags=0) at ../../sys/file.h:156
#19 0xc016841b in write (p=0xc5dca700, uap=0xc62e8f80)
at ../../kern/sys_generic.c:297
#20 0xc024bc9e in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 7461, tf_esi = 7461, tf_ebp = 139553084, tf_isp = -970027052,
tf_ebx = 137571960, tf_edx = 138625036, tf_ecx = 138616616, tf_eax = 4,
tf_trapno = 0, tf_err = 2, tf_eip = 136619508, tf_cs = 31,
tf_eflags = 518, tf_esp = 139553064, tf_ss = 47})
at ../../i386/i386/trap.c:1057
#21 0xc023d386 in Xint0x80_syscall ()
#22 0x819b12a in ?? ()
#23 0x81a793f in ?? ()
#24 0x81a2c37 in ?? ()
#25 0x8171a1c in ?? ()
---Type to continue, or q to quit---
#26 0x8171756 in ?? ()
#27 0x81a385a in ?? ()
#28 0x81a35ec in ?? ()
#29 0x8062f2b in ?? ()
#30 0x806341b in ?? ()
#31 0x8061f98 in ?? ()
#32 0x805e2d7 in ?? ()
#33 0x805dd7c in ?? ()
#34 0x81e8ed8 in ?? ()
#35 0x81e8cea in ?? ()
#36 0xbfbffc48 in ?? ()
#37 0x0 in ?? ()
(kgdb) frame 11
#11 0xc020d194 in vm_page_free_toq (m=0xc04d05b0) at ../../vm/vm_page.c:1080
1080vm_page_remove(m);
(kgdb) p *m
$1 = {pageq = {tqe_next = 0xc04dd7b0, tqe_prev = 0xc02e1e10}, hnext = 0x0,
listq = {tqe_next = 0x0, tqe_prev = 0xc044a18c}, object = 0xc63c62a0,
pindex = 1, phys_addr = 59547648, queue = 0, flags = 0, pc = 10,
wire_count = 0, hold_count = 0, act_count = 0 '\000', busy = 0 '\000',
valid = 255 'ΓΏ', dirty = 0 '\000'}
(kgdb) down
#10 0xc020cb53 in vm_page_remove (m=0xc04d05b0) at ../../vm/vm_page.c:448
448
Re: CVSup core dumps
John, > Also, for those of you who are experiencing problems: Please state > as precisely as possible: I have Oct 4 9pm PDT -current on K6 and SMP PPro machine. CVSup coredumps on K6 machine reliably(?) but it works on SMP PPro machine. I tried both 16.0/15.2(? previous one) packages. Both are the same result. Someone said that it works under truss. It did work with my K6 machine. It smells like something uninitialized is used? > Note, you are going to have trouble getting much out of the core dumps > from the binaries, because they're a.out. I've placed an unstripped > ELF binary here if you'd like to help out by getting a stack trace: > > http://www.freebsd.org/~jdp/cvsup-16.0.gz Great! I was trying to rebuild CVSup by myself, besides I misplaced aout gdb somewhere As your CVSup web page says, it wasn't that straightforward ;-) Thanks Tammy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ping/egcs
Hi,
I just came across the problem with ping and egcs. If you do
# ping -s 57 localhost
PING localhost (127.0.0.1): 57 data bytes
^C
--- localhost ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
if the data size is even number, it works OK. I think that
the problem is that EGCS generates bad code in in_cksum()
with -O.
Compiling with -O0 solves the problem as well as applying
following patch fixes it.
I wonder if how many problems like this go unnoticed
*** ping.c-org Fri Aug 20 09:38:33 1999
--- ping.c Fri Aug 20 09:39:08 1999
***
*** 944,949
--- 944,950
/* mop up an odd byte, if necessary */
if (nleft == 1) {
*(u_char *)(&answer) = *(u_char *)w ;
+ *((u_char *)(&answer)+1) = 0;
sum += answer;
}
Tammy
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: this of interest to anyone?
> There might still be one or two remaining, but these should be very > infrequent. The panice happened during make world with two setiathome clients. Is this a new one or one known to be fixed? Thanks PS: June 30 kernel does not have this problem so far. Tammy Stack trace and dmesg follows: poko# gdb -k kernel.3 vmcore.3 GNU gdb 4.18 Copyright 1998 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-unknown-freebsd"... (no debugging symbols found)... SMP 2 cpus IdlePTD 3223552 initial pcb at 29bac0 panicstr: from debugger panic messages: --- panic: lockmgr: pid 12933, not exclusive lock holder 12948 unlocking mp_lock = 0001; cpuid = 0; lapic.id = panic: from debugger mp_lock = 0002; cpuid = 0; lapic.id = boot() called on cpu#0 dumping to dev (4,131073), offset 262144 dump 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 --- #0 0xc01538fc in boot () (kgdb) where #0 0xc01538fc in boot () #1 0xc0153b7d in panic () #2 0xc012d7c1 in db_panic () #3 0xc012d761 in db_command () #4 0xc012d826 in db_command_loop () #5 0xc012f987 in db_trap () #6 0xc0216d16 in kdb_trap () #7 0xc022c48c in trap () #8 0xc0216f9b in Debugger () #9 0xc0153b74 in panic () #10 0xc014f4d4 in lockmgr () #11 0xc0201cca in relpbuf () #12 0xc01f6a70 in swp_pager_async_iodone () #13 0xc0174633 in biodone () #14 0xc0125c9d in dadone () #15 0xc0121973 in camisr () #16 0xc0121785 in swi_cambio () #17 0xc021c61e in doreti_swi () #18 0x80828fb in ?? () #19 0x805e004 in ?? () #20 0x805bc1e in ?? () #21 0x805c492 in ?? () #22 0x805c373 in ?? () #23 0x80490ff in ?? () ---Type to continue, or q to quit--- #24 0x8084e3e in ?? () #25 0x80878b9 in ?? () #26 0x80480e9 in ?? () (kgdb) quit And dmesg output from a new kernel which survived make world: Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #21: Wed Jun 30 21:38:50 PDT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/POKO Timecounter "i8254" frequency 1193182 Hz CPU: Pentium Pro (686-class CPU) Origin = "GenuineIntel" Id = 0x617 Stepping=7 Features=0xfbff real memory = 134217728 (131072K bytes) avail memory = 127401984 (124416K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfec08000 cpu1 (AP): apic id: 12, version: 0x00040011, at 0xfec08000 io0 (APIC): apic id: 13, version: 0x00170011, at 0xfec0 Preloaded elf kernel "kernel" at 0xc0301000. Pentium Pro MTRR support enabled, default memory type is uncacheable ccd0-3: Concatenated disk drivers Probing for PnP devices: CSN 1 Vendor ID: CSC0b35 [0x350b630e] Serial 0x Comp ID: @@@ [0x] npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 chip0: at device 0.0 on pci0 fxp0: irq 18 at device 6.0 on pci0 fxp0: Ethernet address 00:a0:c9:55:32:47 isab0: at device 7.0 on pci0 ide_pci0: at device 7.1 on pci0 chip1: irq 10 at device 7.2 on pci0 ahc0: irq 17 at device 9.0 on pci0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs vga-pci0: irq 16 at device 11.0 on pci0 isa0: on motherboard fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> at fdc0 drive 0 atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 vga0: at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2: not probed (disabled) sio3: not probed (disabled) ppc0 at port 0x378-0x37f irq 7 flags 0x40 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: on ppbus 0 lpt0: on ppbus 0 lpt0: Interrupt-driven port ppi0: on ppbus 0 APIC_IO: routing 8254 via 8259 on pin 0 Waiting 2 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! changing root device to da0s1a da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 8705MB (17829870 512 byte sectors: 255H 63S/T 1109C) da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers
Re: this of interest to anyone?
> panic: lockmgr: pid 3344, not exclusive lock holder 3341 unlocking I had the similar panic last night during make world. I have a dump at home but I didn't have time to take a look this morning. My system is dual PPro SMP, 128MB RAM, 3 SCSI UW disks with CCD, about two day old -current. Since the panic happened after update source tree (I should have saved it), I don't have kernel source code for the /kernel. I'll post the details if no one else reports the details when I get home. Tammy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic on reboot
Bob, > For a few weeks, I've been seeing a double fault panic on rebooting after > building world followed by kernel. The panic hits right after "syncing > disks... done". It doesn't seem to happen if the machine hasn't done a fair > bit of work since last reboot, and it's happening on two separate machines > (one is SMP). Do you happen to have non-existing devices in kernel config file? I have been seeing the double fault panic on SMP system. It seemed to be related to non-existing device when I looked at it with debugger. When I got rid of unnecessary devices from config file, the panic went away. I didn't investigate which device was causing it, though. Tammy To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: worldstone improvement...
> My 2 x 233MHz PPro has improved make world time by about 100 seconds > out of 5000s = 2 % My dual 200MHz PPro worldstone also improved almost 3 minutes (173 seconds) after Luoqi's SMP change. I think it's good improvement. Tammy To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
