Re: cvs commit: src/sys/kern sys_process.c
This will not fix the problem. I even removed rev 1.57-1.58 and it still causes gdb to lockup the system. Szilveszter Adam ([EMAIL PROTECTED]) wrote: Hello everybody! ps 2000/12/29 16:44:44 PST Modified files: sys/kern sys_process.c Log: Pass me the pointy hat. Do not hold sched_lock over psignal. Submitted by: alfred Revision ChangesPath 1.58 +2 -2 src/sys/kern/sys_process.c I think I will try this. Maybe it will help with the panic I saw yesterday. Will report back when I am done. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Paul Saab Technical Yahoo [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] Do You .. uhh .. Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current stalls...(now also panic)
On Fri, Dec 29, 2000 at 10:57:10PM +0100, Szilveszter Adam wrote: Hi! Maybe this is related, maybe not... I upgraded to the latest CURRENT available this morning and now I also see occasional (albeit short) hangs sometimes, although the machine seems to be responsive otherwise. But, not only that, I also got a cool panic while trying to do some stuff (like compiling the docs) and pressing Ctrl-Z in another tty. No X, no nothing. I was dropped into the debugger, but since I am not a ddb artist, I tried to avoid to type the whole trace by hand and in the process managed to reboot the box... oh well. Next time I will know. But, the panic message was this: panic: blockable mtx_enter() of lockmgr interlock when not legal @ ../../kern/kern_lock.c:247 Maybe this rings a bell with someone. The error was appearently caught by WITNESS, which I also have enabled in my kernel (albeit without MUTEX_DEBUG, because *that* really made it impossible to do anything sensible on the machine...) I see the same panic. I managed to collect some info in kern/23935. http://www.freebsd.org/cgi/query-pr.cgi?pr=23935 I can reliably reproduce it. -- Alex Kapranoff, Voice: +7(0832)791845 36 hours before the brand new millenium... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: possible fix for gdb hanging the kernel
On Fri, Dec 29, 2000 at 04:19:38PM -0800, Alfred Perlstein wrote:
I'd appreciate it if those who are having issues with gdb were to
try this patch and let me know if it fixes things.
Sorry, but gdb keeps hanging my box after this patch.
In fact, the behaviour didn't changed.
Index: sys_process.c
===
RCS file: /home/ncvs/src/sys/kern/sys_process.c,v
retrieving revision 1.57
diff -u -u -r1.57 sys_process.c
--- sys_process.c 2000/12/28 08:34:21 1.57
+++ sys_process.c 2000/12/30 00:24:38
@@ -381,8 +381,8 @@
if (p-p_stat == SSTOP) {
p-p_xstat = uap-data;
setrunnable(p);
- psignal(p, SIGCONT);
mtx_exit(sched_lock, MTX_SPIN);
+ psignal(p, SIGCONT);
} else {
mtx_exit(sched_lock, MTX_SPIN);
if (uap-data) {
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
--
Alex Kapranoff, Voice: +7(0832)791845
1 days before the brand new millenium...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
-current hang workaround
This gives an almost -current kernel without the hangs: setenv TZ PST8PDT cvs -q update -P -d -D "2000-12-26 10:00" -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic: lockable mtx_enter
panic: lockable mtx_enter() of lockmgr interlock when not legal @ ../../kern/kern_lock.c: 247 which is mtx_enter(lkp-lk_interlock, MTX_DEF); my system is an i386 UP with two dc cards and a kernel configured as follows: machine i386 cpu I586_CPU cpu I686_CPU ident MYKERNEL maxusers32 hints "GENERIC.hints" #Default places to look for devices. #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols options INET#InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support #optionsMFS #Memory Filesystem options MD_ROOT #MD is a potential root device #optionsNFS #Network Filesystem #optionsNFS_ROOT#NFS usable as root device, NFS required options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options CD9660_ROOT #CD-ROM usable as root, CD9660 required options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options UCONSOLE#Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV# install a CDEV entry in /dev device random #entropy device #optionsRANDOMDEV device isa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering options ATA_ENABLE_ATAPI_DMA#Enable DMA on ATAPI devices # SCSI Controllers #device adv # SCSI peripherals device scbus # SCSI bus (required) device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass# Passthrough device (direct SCSI access) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc 1 device atkbd device psm device vga # splash screen/screen saver device splash # syscons is the default console driver, resembling an SCO console device sc 1 # Floating point support - do not disable. device npx # Power management support (see LINT for more options) device apm # PCCARD (PCMCIA) support #device card #device pcic # Serial (COM) ports device sio # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device ppi # Parallel port interface device #device vpo # Requires scbus and da # PCI Ethernet NICs that use the common MII bus controller code. device miibus # MII bus support device dc # DEC/Intel 21143 and various workalikes # Pseudo devices - the number indicates how many units to allocated. device loop# Network loopback device ether # Ethernet support device sl # Kernel SLIP device ppp 1 # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif 4 # IPv6 and IPv4 tunneling device faith 1 # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf 2 # Berkeley packet filter # USB support #device uhci# UHCI PCI-USB interface #device ohci# OHCI PCI-USB interface #device usb # USB Bus (required) #device udbp# USB Double Bulk Pipe devices #device
CVSup to CURRENT failing when building new kernel (fwd)
Please respond directly to [EMAIL PROTECTED] as I am not on this mailing list.. I am hoping that this is not something I am doing wrong ... the procedur ei followed was cvsup src and ports... using supfile in handbook for going to current.. from there i did /usr/src make buildworld then make installworld and ffom there i did make buildkernel KERNEL=GENERIC and then make installkernel KERNEL=GENERIC and i get the following errors.. please help as I am itching to get this resolved... make installkernel KERNEL=GENERIC cd /usr/obj/usr/src/sys/GENERIC; MAKEOBJDIRPREFIX=/usr/obj COMPILER_PATH=/usr/obj/usr/src/i386/usr/libexec:/usr/obj/usr/src/i386/usr/bin LIBRARY_PATH=/usr/obj/usr/src/i386/usr/lib:/usr/obj/usr/src/i386/usr/lib OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.6.0 MACHINE=i386 make KERNEL=kernel install You must set up a /boot/device.hints file first. *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Thanks in advance... raymond hicks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: lockable mtx_enter
On Sat, Dec 30, 2000 at 09:41:08AM -0600, Michael Harnois wrote:
panic: lockable mtx_enter() of lockmgr interlock when not legal @
../../kern/kern_lock.c: 247
Hello!
OK, so since nobody has done it before me, I just decided to investigate a
bit. Remember, that I am not a kernel hacker, so I might be completely
off-base with what I have done. (In which case, feel free to toast me)
Machine:
FreeBSD fonix.hos.u-szeged.hu 5.0-CURRENT FreeBSD 5.0-CURRENT #14: Sat Dec
30 15
:04:55 CET 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/FONIX
i386
Problem:
When using ftp, and either a transfer or a dir listing is in progress,
hitting Ctrl-Z in the terminal on which ftp runs causes a panic. When ftp
just sits there waiting for ttyin, Ctrl-Z works just fine.
This is the same panic as the one described in kern/23935, but no ppp is
needed, it just works:-)
Other symptoms:
Maybe related, network performance on my RealTek 8029 (ed) PCI card is
impacted since the last upgrade (today). Especially ssh performance goes
down the toilet from time to time (which
makes it a real PITA to type this letter on our mail server, but machine
itself is not allowed to send mail because of firewall...) ie characters
appear with high latency, connection appears to be hung. Interestingly,
disk activity is *not* impacted, somehow keyboard and network interact in
non-favorable ways. (ie I can listen to mp3s as I want, it doesn't even
stutter, also build/installworld and rm -rf /usr/obj/* completed without
any problems and within normal time-frame.)
Measures:
After finding out how to reproduce the panic, I broke out my FM radio and
took a crash dump. (it's almost party time, after all...) and fired up gdb.
Poked around some, since the bt posted in the PR is appearently from
non-debug kernel, and am including the transscript here. I do not think
there is anything unusual about my kernel config and dmesg, but if you
think they are interesting, I can post those.
Next:
I think I am going to build a new kernel with MUTEX_DEBUG to see if
anything changes. But I do not have the skillz (even after looking at how
some of the maestros do it on these lists:-) to investigate a lot more, so
if you have any ideas at all as to where to go from here, I will gladly
follow... the machine *can* afford downtime:-) (but crash dumps tend to be
big since i have 128M of RAM:-)
Thoughts? Flames?:-)
--
Regards:
Szilveszter ADAM
Szeged University
Szeged Hungary
Script started on Sat Dec 30 17:48:55 2000
[1m[17:48, Dec 30., Sat][m cc@fonix:[1m/usr/src/sys/compile/FONIX[m ttyp0 [1m#[m
gdb -k
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".
(kgdb) symbol-file kernel.debug
Reading symbols from kernel.debug...done.
(kgdb) exec-file /var/crash/kernel.0
(kgdb) core-file /var/crash/vmcore.0
IdlePTD 4980736
initial pcb at 3c7120
panicstr: blockable mtx_enter() of lockmgr interlock when not legal @
../../kern/kern_lock.c:247
panic messages:
---
panic: blockable mtx_enter() of lockmgr interlock when not legal @
../../kern/kern_lock.c:247
syncing disks... 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
1: dev:#ad/0x20003, flags:21021024, blkno:144, lblkno:144
2: dev:#ad/0x20006, flags:21021024, blkno:3014976, lblkno:3014976
3: dev:#ad/0x20003, flags:21021024, blkno:196672, lblkno:196672
giving up on 3 buffers
Uptime: 30m17s
dumping to dev #ad/0x20001, offset 352256
dump ata0: resetting devices .. done
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 dumpsys () at ../../kern/kern_shutdown.c:477
477 if (dumping++) {
(kgdb) where bt
#0 dumpsys () at ../../kern/kern_shutdown.c:477
#1 0xc01b94a7 in boot (howto=256) at ../../kern/kern_shutdown.c:320
#2 0xc01b9871 in panic (
fmt=0xc032cce0 "blockable mtx_enter() of %s when not legal @ %s:%d")
at ../../kern/kern_shutdown.c:570
#3 0xc01b3c23 in witness_enter (m=0xc0b54e00, flags=0,
file=0xc032bcfa "../../kern/kern_lock.c", line=247)
at ../../kern/kern_mutex.c:875
#4 0xc01b0ab6 in lockmgr (lkp=0xc03f2260, flags=1, interlkp=0x0, p=0xcbbb4740)
at ../../sys/mutex.h:528
#5 0xc01baf44 in psignal (p=0xcbbb2320, sig=18) at ../../kern/kern_sig.c:1161
#6 0xc01baa89 in pgsignal (pgrp=0xc269c020, sig=18, checkctty=1)
at
IGMP queries
My isp's router is sending me IGMP queries. 18:25:07.850008 212.242.151.2 224.0.0.1: 212.242.151.2 224.0.0.1: igmp v2 query [intvl 10]igmp query [ttl 1] I think it keeps my user-ppp connection open, even if I have this rule in my firewall: $fwcmd add 65432 deny ip from 212.242.151.2 to any If it is true, how can I filter it to stop resetting the idle-timeout? I'm on flat rate now, but even so I don't want to be online 24h/day... Btw, can I use IGMP to something useful/interesting/funny? Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVSup to CURRENT failing when building new kernel (fwd)
On Sat, Dec 30, 2000 at 11:58:05AM -0500, Raymond Hicks wrote: Please respond directly to [EMAIL PROTECTED] as I am not on this mailing list.. I am hoping that this is not something I am doing wrong ... the procedur ei followed was cvsup src and ports... using supfile in handbook for going to current.. from there i did /usr/src make buildworld then make installworld and ffom there i did make buildkernel KERNEL=GENERIC and then make installkernel KERNEL=GENERIC and i get the following errors.. please help as I am itching to get this resolved... make installkernel KERNEL=GENERIC cd /usr/obj/usr/src/sys/GENERIC; MAKEOBJDIRPREFIX=/usr/obj COMPILER_PATH=/usr/obj/usr/src/i386/usr/libexec:/usr/obj/usr/src/i386/usr/bin LIBRARY_PATH=/usr/obj/usr/src/i386/usr/lib:/usr/obj/usr/src/i386/usr/lib OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.6.0 MACHINE=i386 make KERNEL=kernel install You must set up a /boot/device.hints file first. Isn't the message poroducing the error explaining enough? Reading the UPDATING file would have told you the same and is very important when updating the system. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
getlogin_r broken
POSIX says that getlogin_r should return an int, not a char *. Our implementation is also broken; it will only work the first time. Since we've already bumped libc version number, anyone mind if I fix it? -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: lockable mtx_enter
A checkin was just made that fixed a mutex that was being held incorrectly in psignal, which features in your stack trace. It's possible that this has been fixed in the last 24 hours. Szilveszter Adam wrote: On Sat, Dec 30, 2000 at 09:41:08AM -0600, Michael Harnois wrote: panic: lockable mtx_enter() of lockmgr interlock when not legal @ ../../kern/kern_lock.c: 247 Hello! OK, so since nobody has done it before me, I just decided to investigate a bit. Remember, that I am not a kernel hacker, so I might be completely off-base with what I have done. (In which case, feel free to toast me) Machine: FreeBSD fonix.hos.u-szeged.hu 5.0-CURRENT FreeBSD 5.0-CURRENT #14: Sat Dec 30 15 :04:55 CET 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/FONIX i386 Problem: When using ftp, and either a transfer or a dir listing is in progress, hitting Ctrl-Z in the terminal on which ftp runs causes a panic. When ftp just sits there waiting for ttyin, Ctrl-Z works just fine. This is the same panic as the one described in kern/23935, but no ppp is needed, it just works:-) Other symptoms: Maybe related, network performance on my RealTek 8029 (ed) PCI card is impacted since the last upgrade (today). Especially ssh performance goes down the toilet from time to time (which makes it a real PITA to type this letter on our mail server, but machine itself is not allowed to send mail because of firewall...) ie characters appear with high latency, connection appears to be hung. Interestingly, disk activity is *not* impacted, somehow keyboard and network interact in non-favorable ways. (ie I can listen to mp3s as I want, it doesn't even stutter, also build/installworld and rm -rf /usr/obj/* completed without any problems and within normal time-frame.) Measures: After finding out how to reproduce the panic, I broke out my FM radio and took a crash dump. (it's almost party time, after all...) and fired up gdb. Poked around some, since the bt posted in the PR is appearently from non-debug kernel, and am including the transscript here. I do not think there is anything unusual about my kernel config and dmesg, but if you think they are interesting, I can post those. Next: I think I am going to build a new kernel with MUTEX_DEBUG to see if anything changes. But I do not have the skillz (even after looking at how some of the maestros do it on these lists:-) to investigate a lot more, so if you have any ideas at all as to where to go from here, I will gladly follow... the machine *can* afford downtime:-) (but crash dumps tend to be big since i have 128M of RAM:-) Thoughts? Flames?:-) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary Name: debug.txt debug.txtType: Plain Text (text/plain) Encoding: quoted-printable -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern sys_process.c
On 30-Dec-00 Paul Saab wrote: This will not fix the problem. I even removed rev 1.57-1.58 and it still causes gdb to lockup the system. Try backing out the proctree lock. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "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
RE: panic: lockable mtx_enter
On 30-Dec-00 Michael Harnois wrote: panic: lockable mtx_enter() of lockmgr interlock when not legal @ ../../kern/kern_lock.c: 247 which is mtx_enter(lkp-lk_interlock, MTX_DEF); We need to know where interrupts were disabled (since that is what makes the blockable mtx_enter() not legal). The most likely reason is that sched_lock is held. Take a crash dump if you can, and then examine the '__mtx_debug_sched_lock' variable. Esp. the mtxd_line and mtd_file members which tell us where sched_lock was last acquired. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "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
Re: panic: lockable mtx_enter
On Sat, Dec 30, 2000 at 11:46:15AM -0800, Julian Elischer wrote: A checkin was just made that fixed a mutex that was being held incorrectly in psignal, which features in your stack trace. It's possible that this has been fixed in the last 24 hours. Hello Julian! If you are referring to the commit made by ps to sys/kern/sys_process.c, than nope, that is not it. I already have the latest revision of that file and the problem report was sent *after* the upgrade:-( (I was also hoping, but...) In the meantime, I compiled and booted a kernel with MUTEX_DEBUG, reproduced the panic, but the stack trace did not look differently at all. On the upside, the new option did not render my machine nearly unusable as it did on a previous occassion when I tried it... as said, disk activity is unaffected. (And yes, I even can use cvsup to update my sources, so far, so good. But it is slow.) I am stumped here... I know next to nothing about how the locking system works but my private theory is that somehow network processes (the actual network part) do not get their priority right. Eg when I use w3m, the browsing works as long as I stay on the same page, as works the back function. But as soon as it has to load a page, it hangs for a long time, and then is allowed to complete its job burst-like... same for ssh... Next I will try to see to what extent the console is involved... eg I'll go and do a network login and see if things are any different... But surely this is annoying... I had hoped that on New Year's Party FreeBSD would rock da house:-) (although the mp3 player still works fine, sooo...) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: lockable mtx_enter
On Sat, Dec 30, 2000 at 12:08:48PM -0800, John Baldwin wrote:
On 30-Dec-00 Michael Harnois wrote:
panic: lockable mtx_enter() of lockmgr interlock when not legal @
../../kern/kern_lock.c: 247
which is
mtx_enter(lkp-lk_interlock, MTX_DEF);
We need to know where interrupts were disabled (since that is what makes the
blockable mtx_enter() not legal). The most likely reason is that sched_lock is
held. Take a crash dump if you can, and then examine the
'__mtx_debug_sched_lock' variable. Esp. the mtxd_line and mtd_file members
which tell us where sched_lock was last acquired.
John,
I can already supply the needed information.
(kgdb) print __mtx_debug_sched_lock
$1 = {mtxd_witness = 0xc03d98f0, mtxd_held = {le_next = 0x0, le_prev =
0x0},
mtxd_file = 0xc033c27c "../../kern/kern_sig.c", mtxd_line = ,
mtxd_description = 0xc0368cbf "sched lock"}
and:
(kgdb) print __mtx_debug_sched_lock-mtxd_line
$2 =
(kgdb) list $2
1106if (!witness_watch)
1107return (NULL);
1108for (ignore = ignore_list; *ignore != NULL; ignore++)
1109if (strcmp(description, *ignore) == 0)
1110return (NULL);
1112if (w_inited == 0) {
1113mtx_init(w_mtx, "witness lock", MTX_COLD |
MTX_SPIN);
1114for (i = 0; i WITNESS_COUNT; i++) {
1115w = w_data[i];
(kgdb) print __mtx_debug_sched_lock-mtxd_file
$3 = 0xc033c27c "../../kern/kern_sig.c"
If you have any more questions... don't hesitate to contact me.
--
Regards:
Szilveszter ADAM
Szeged University
Szeged Hungary
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic: lockable mtx_enter
On Sat, Dec 30, 2000 at 12:23:58PM -0800, John Baldwin wrote:
On 30-Dec-00 Szilveszter Adam wrote:
On Sat, Dec 30, 2000 at 12:08:48PM -0800, John Baldwin wrote:
On 30-Dec-00 Michael Harnois wrote:
panic: lockable mtx_enter() of lockmgr interlock when not legal @
../../kern/kern_lock.c: 247
which is
mtx_enter(lkp-lk_interlock, MTX_DEF);
We need to know where interrupts were disabled (since that is what makes the
blockable mtx_enter() not legal). The most likely reason is that sched_lock
is
held. Take a crash dump if you can, and then examine the
'__mtx_debug_sched_lock' variable. Esp. the mtxd_line and mtd_file members
which tell us where sched_lock was last acquired.
John,
I can already supply the needed information.
(kgdb) print __mtx_debug_sched_lock
$1 = {mtxd_witness = 0xc03d98f0, mtxd_held = {le_next = 0x0, le_prev =
0x0},
mtxd_file = 0xc033c27c "../../kern/kern_sig.c", mtxd_line = ,
mtxd_description = 0xc0368cbf "sched lock"}
That's line of sys/kern/kern_sig.c:
Yes, sorry I goofed up ... I am just very new to gdb...
/*
* Defer further processing for signals which are held,
* except that stopped processes must be continued by SIGCONT.
*/
mtx_enter(sched_lock, MTX_SPIN);
if (action == SIG_HOLD (!(prop SA_CONT) || p-p_stat != SSTOP)) {
mtx_exit(sched_lock, MTX_SPIN);
return;
}
Hmm, ok, which signal is this?
In the case in point, it is SIGTSTP (Ctrl-Z)
--
Regards:
Szilveszter ADAM
Szeged University
Szeged Hungary
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic: lockable mtx_enter
On 30-Dec-00 Szilveszter Adam wrote:
On Sat, Dec 30, 2000 at 12:23:58PM -0800, John Baldwin wrote:
On 30-Dec-00 Szilveszter Adam wrote:
On Sat, Dec 30, 2000 at 12:08:48PM -0800, John Baldwin wrote:
On 30-Dec-00 Michael Harnois wrote:
panic: lockable mtx_enter() of lockmgr interlock when not legal @
../../kern/kern_lock.c: 247
which is
mtx_enter(lkp-lk_interlock, MTX_DEF);
We need to know where interrupts were disabled (since that is what makes
the
blockable mtx_enter() not legal). The most likely reason is that
sched_lock
is
held. Take a crash dump if you can, and then examine the
'__mtx_debug_sched_lock' variable. Esp. the mtxd_line and mtd_file
members
which tell us where sched_lock was last acquired.
John,
I can already supply the needed information.
(kgdb) print __mtx_debug_sched_lock
$1 = {mtxd_witness = 0xc03d98f0, mtxd_held = {le_next = 0x0, le_prev =
0x0},
mtxd_file = 0xc033c27c "../../kern/kern_sig.c", mtxd_line = ,
mtxd_description = 0xc0368cbf "sched lock"}
That's line of sys/kern/kern_sig.c:
Yes, sorry I goofed up ... I am just very new to gdb...
That's ok. I seem to have goofed up in kern_sig.c. Please try the (untested)
patch at http://www.FreeBSD.org/~jhb/patches/kern_sig.patch.
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc
"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
Re: panic: lockable mtx_enter
On Sat, Dec 30, 2000 at 12:36:36PM -0800, John Baldwin wrote: That's ok. I seem to have goofed up in kern_sig.c. Please try the (untested) patch at http://www.FreeBSD.org/~jhb/patches/kern_sig.patch. OK, trying it right now... it applied cleanly, but it will take sometime until the compile finishes. (this PII233 is not exactly a speedwagon any longer...) I will keep you posted about the results. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: lockable mtx_enter
On Sat, Dec 30, 2000 at 12:36:36PM -0800, John Baldwin wrote: That's ok. I seem to have goofed up in kern_sig.c. Please try the (untested) patch at http://www.FreeBSD.org/~jhb/patches/kern_sig.patch. Well, the kernel is ready and the patch appears to work. Ie I can run a large dirlisting on an ftp server, and press Ctrl-Z in the meantime and still no problem. So, appearently kern/23935 can be put into feedback state... However, the network unresponsiveness problem remains (of course) and may be harder to debug since it does not produce a panic but rather abysmal performance... will try to observe things more tomorrow, today it is late... Also, the gdb issue is still worth looking into... (Yes I tried that, but there is *nothing* even in a crash dump that would make the cause stand out...) John, thanks for fixing this problem! (Now I can try to get the new gimp...) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current hangs...
A bug in specfs's fsync dating back to Kirk's original softupdates work
( which required a similar mark/scan fix to the FFS fsync ) appears to
have been exposed by recent pageout peformance commits I made.
I've committed a mark/scan fix to specfs's fsync, which appears
to solve the lockups Poul was getting doing a 'cvs update -PdA' under
-current. It should solve the problem for the other two people who
reported the same lockup.
I'm not sure why -stable isn't affected. The bug is in -stable as well.
I'll MFC it in two days unless I see complaints sooner. It's a simple
bug fix.
At some point I need to go through all the fsync implementations...
they need the same sort of placemarker fix that I threw into the
pageout daemon scan. The current code uses the 'goto loop' hack, which
is terribly inefficient when combined with a heavily loaded
softupdates-enabled system.
-Matt
Index: spec_vnops.c
===
RCS file: /home/ncvs/src/sys/miscfs/specfs/spec_vnops.c,v
retrieving revision 1.147
retrieving revision 1.148
diff -u -r1.147 -r1.148
--- spec_vnops.c2000/12/26 19:41:37 1.147
+++ spec_vnops.c2000/12/30 23:32:24 1.148
@@ -31,7 +31,7 @@
* SUCH DAMAGE.
*
* @(#)spec_vnops.c8.14 (Berkeley) 5/21/95
- * $FreeBSD: src/sys/miscfs/specfs/spec_vnops.c,v 1.147 2000/12/26 19:41:37 dillon
Exp $
+ * $FreeBSD: src/sys/miscfs/specfs/spec_vnops.c,v 1.148 2000/12/30 23:32:24 dillon
+Exp $
*/
#include sys/param.h
@@ -352,12 +352,25 @@
return (0);
/*
+* MARK/SCAN initialization to avoid infinite loops
+*/
+ s = splbio();
+for (bp = TAILQ_FIRST(vp-v_dirtyblkhd); bp;
+ bp = TAILQ_NEXT(bp, b_vnbufs)) {
+bp-b_flags = ~B_SCANNED;
+ }
+ splx(s);
+
+ /*
* Flush all dirty buffers associated with a block device.
*/
loop:
s = splbio();
for (bp = TAILQ_FIRST(vp-v_dirtyblkhd); bp; bp = nbp) {
nbp = TAILQ_NEXT(bp, b_vnbufs);
+ if ((bp-b_flags B_SCANNED) != 0)
+ continue;
+ bp-b_flags |= B_SCANNED;
if (BUF_LOCK(bp, LK_EXCLUSIVE | LK_NOWAIT))
continue;
if ((bp-b_flags B_DELWRI) == 0)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: IGMP queries
On Sat, Dec 30, 2000 at 18:32 +0100, Leif Neland wrote: My isp's router is sending me IGMP queries. 18:25:07.850008 212.242.151.2 224.0.0.1: 212.242.151.2 224.0.0.1: igmp v2 query [intvl 10]igmp query [ttl 1] Ask your provider to not do it. :) Do you run any multicast enabled applications, anyhow? If not, all of the 224.0.0.0/4 stuff is not needed ... I think it keeps my user-ppp connection open, even if I have this rule in my firewall: $fwcmd add 65432 deny ip from 212.242.151.2 to any If it is true, how can I filter it to stop resetting the idle-timeout? If you use ppp(8) -- you don't state what your uplink looks like, whether it's an analog modem / ISDN / DSL / plain ethernet / whatever -- there are four filter lists: those packets allowed to pass in, those to pass out, those to trigger dialing and those to keep the session alive. All the lists can be positive or negativ, but are somewhat limited in their length and flexibility. Maybe this feature will help you, although all of the above is what I got from reading "man 8 ppp" and not from personal experience. :( Btw, can I use IGMP to something useful/interesting/funny? AFAIK it's some kind of dynamic route establishment (learning about topology by listening to what your neighbour knows about the network). Home users and small LANs won't need it IMHO, maybe WAN links will benefit? But I'm definitely not keen on having "the world" tell me where to send my packets to. I just hand the traffic to my provider's dialin port. : virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
no more network probs
Hello! I just wanted to tell you quickly that you can scrap the vague reports I made about network problems yesterday... (including ssh and ftp hangs...) *Sigh...* I thought I was quite sure it was a FreeBSD problem, processes really appeared to be hung. And besides, never thought that packet loss rates of up to 80% could be normal on a University network during the holidays... (no, I am *not* the network admin or something here...) But now everything appears to be working normally, even with MUTEX_DEBUG set, including the beast named 'realplay':-) So now FreeBSD is ready to rock the new Millennium tonight:-) (BTW I could not see the patch John Baldwin posted here yesterday committed - the one about the SIGTSTP problem... have been any problems reported?) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
