Unstable ISDN with interrupt preemption?
Hi, I just noticed very unstable ISDN connections since the introduction of preempted interrupt threads (Jan 31st). Most errors are uncritical though, an active connection continues to work, sometimes I have to restart isdnd, and sometimes I even have to reboot the machine. The "i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout!" seem to have been introduced by the SMPng code, but with interrupt preemption they appear more often (I switched th SMPng on Jan 25th) As you can also see on the output: On Feb 9th I rebooted the machine with a newly built kernel. All other errors besides the one mentioned above suddenly disappeared. A quick look at the change logs revealed: preemption was accidently removed for interrupt threads on Feb 9th - and reintroduced a few hours later. It seems I was running such a kernel for a week (Feb 9th - 18th) Anyone else having the same problem? -- Daniel Jan 27 18:24:08 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Jan 28 06:26:32 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 3 00:26:13 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 3 12:23:38 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 3 12:33:38 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 3 12:35:38 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 3 14:53:38 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 3 15:05:00 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 3 15:26:08 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 6 00:26:15 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 6 12:14:49 gate /boot/kernel/kernel: i4b-L2 i4b_rxd_ack: ((N(R)-1)=115) != (UA=116) !!! Feb 7 00:19:47 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 7 06:21:56 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 7 06:27:56 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 7 12:24:55 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 7 21:54:51 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 8 00:24:50 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 8 00:31:50 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 9 20:53:51 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 9 20:53:51 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 9 21:07:33 gate /boot/kernel/kernel: i4b-L1 isic_isac_exir_hdlr: EXIRQ Rx Frame Overflow Feb 9 21:13:56 gate /boot/kernel/kernel: i4b-L2 i4b_T200_timeout: unit 0, RC = 0 Feb 9 21:14:25 gate /boot/kernel/kernel: i4b-L3 T305_timeout: DISC not answered, cr = 126 Feb 9 21:14:26 gate /boot/kernel/kernel: i4b-L3 T308_timeout: REL not answered, cr = 126 Feb 9 21:14:36 gate /boot/kernel/kernel: i4b-L3 T303_timeout: SETUP not answered, cr = 108 Feb 9 21:17:44 gate /boot/kernel/kernel: i4b-L2 i4b_T200_timeout: unit 0, RC = 0 Feb 9 21:17:44 gate /boot/kernel/kernel: i4b-L2 F_ILL: FSM function F_ILL executing Feb 9 21:17:44 gate /boot/kernel/kernel: i4b-L2 i4b_next_l2state: FSM illegal state, state = ST_TEI_UNAS, event = EV_T200EXP! Feb 9 21:17:49 gate /boot/kernel/kernel: i4b-L2 i4b_i_frame_queued_up: ERROR, mbuf NULL after IF_DEQUEUE Feb 9 21:17:49 gate /boot/kernel/kernel: i4b-L2 i4b_i_frame_queued_up: ERROR, mbuf NULL after IF_DEQUEUE Feb 10 18:24:22 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 13 18:20:48 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 16 18:21:03 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 18 00:24:59 gate /boot/kernel/kernel: i4b-L1 isic_isac_exir_hdlr: EXIRQ Rx Frame Overflow Feb 18 00:25:59 gate /boot/kernel/kernel: i4b-L1 isic_isac_exir_hdlr: EXIRQ Rx Frame Overflow Feb 18 02:05:00 gate /boot/kernel/kernel: i4b-L1 isic_isac_exir_hdlr: EXIRQ Rx Frame Overflow Feb 18 02:05:00 gate /boot/kernel/kernel: i4b-L1 isic_isac_exir_hdlr: EXIRQ Rx Frame Overflow Feb 18 02:23:05 gate /boot/kernel/kernel: i4b-L1 isic_isac_exir_hdlr: EXIRQ Rx Frame Overflow Feb 18 02:23:05 gate /boot/kernel/kernel: i4b-L2 i4b_mdl_error_ind: unit = 0, location = F_MF07 Feb 18 02:23:05 gate /boot/kernel/kernel: i4b-L2 i4b_mdl_error_ind: error = MDL_ERR_F: peer initiated re-establishment - SABME Feb 19 00:27:30 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 19 23:35:50 gate /boot/kernel/kernel: i4b-L1 isic_hscx_waitxfw: HSCX wait for XFW timeout! Feb 20 18:25:00 gate
Re: Today's panic :-)
Warner Losh wrote: I've added INVARIANTS and WITNESS to my kernel. Today I get a random panic on boot sometimes: lock order reseral (this doesn't cause the panic, but does seem to happen all the time) 1st vnode interlock last acquired @ ../../usr/ffs/ffs_fsops.c:396 2nd 0xc04837a0 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:457 3rd 0xc80b9e8c vnode interlock @ ../../kern/vfs_subr.c:1872 I keep dropping into ddb with: ad1: 99MB VMware Inc. Virtual Hard Drive [216/15/63] at ata0-slave WDMA2 Mounting root from ufs:/dev/ad0s1a lock order reversal 1st lockmgr last acquired @ ../../kern/kern_lock.c:239 2nd 0xc085d654 ucred @ ../../kern/kern_prot.c:1177 3rd 0xc02b65e0 lockmgr @ ../../kern/kern_lock.c:239 lock order reversal 1st vnode interlock last acquired @ ../../kern/vfs_vnops.c:625 2nd 0xc02d0a60 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:940 3rd 0xc3d7186c vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:949 lock order reversal 1st lockmgr last acquired @ ../../kern/kern_lock.c:239 2nd 0xc02b8620 uidinfo hash @ ../../kern/kern_resource.c:765 3rd 0xc02b65e0 lockmgr @ ../../kern/kern_lock.c:239 lock order reversal 1st lockmgr last acquired @ ../../kern/kern_lock.c:239 2nd 0xc08d321c uidinfo struct @ ../../kern/kern_resource.c:819 3rd 0xc02b65e0 lockmgr @ ../../kern/kern_lock.c:239 hitting 'c' (for continue) allows me to go on This with a kernel CVSUP'd in the last day. I'll CVsup again as I vaguely remember a commit message that may affect this. -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
find / -fstype local traverses non-local filesystems
On Sat, 24 Feb 2001 17:04:44 +1030, Matthew Thyer [EMAIL PROTECTED] said: find seems to be traversing all file systems (local and non-local) but just not reporting the found file when its on a non-local filesystem. As has been discussed many times before, this is correct behavior. If you want `find' to not traverse a directory, use the `-prune' primary. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dirty buffers on reboot again?
Robert Watson wrote: Hmm. I've been getting this on an ATA box as well. Don't seem to get it when softupdates is not set on the root partition, but that's just an observation from a couple of boxes. (Sample size == 2 - confidence level = 0). I don't have softupdates on root (but I do have elsewhere... which reminds me I need to turn it on on a recently created partition :). -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Acabou o hipismo-arte. Mas a desculpa brasileira mais ouvida em Sydney e' que nao tem mais cavalo bobo por ai'. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: as segfaulting during world-build
Warner Losh schrieb: In message [EMAIL PROTECTED] Daniel Rock writes: : I did have the same problem. But just rebuilding binutils didn't help either. : Trying to rebuild libc resulted in above SEGV from as. Some sort of Catch 22 Find a libc from before Feb 10th or after Feb 21 and put it on your system. Yes I know, I already posted another solution: Just use another /usr/lib/libc.so.4 for rebuilding libc.so.5 Sometimes you just have at this time no working internet connection - and you simply cannot find your backup tapes you never made. So I came around the trick with an older libc.so.4, which seems to be "compatible enough" to let me rebuild libc. -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/dev/acpica/Osd OsdSchedule.c src/sys/i386/i386 genassym.c swtch.strap.c src/sys/ia64/ia64 trap.c src/sys/kern init_main.c kern_condvar.ckern_idle.c kern_intr.c kern_mib.c kern_mutex.c kern_proc.c ...
Bruce Evans schrieb: On Thu, 22 Feb 2001, Daniel Rock wrote: You may have forgotten to also change KINFO_PROC_SIZE in src/sys/user.h Yes, rev.1.31 of src/sys/sys/user.h leaves it as an exercise to change KINFO_PROC_SIZE. I hate doing such exercises, since it will be followed by some nasty other exercises: Clean up your conflicting cvs files... WARNING: size of kinfo_proc (648) should be 644!!! This is normal if you haven't done the exercise. It is just a warning. This seems to be a "non required" exercise, since even if you fail solving it, your machine continues working... BTW What is the purpose of KINFO_PROC_SIZE? Why not simply using sizeof()? It is to inhibit changes in the size of the struct. Such changes would break the interface. The struct must have a certain fixed size (and layout) for binary compatibility. sizeof() would give the current size, not necessarily the size that is required for compatibility. But: Since the introduction of KINFO_PROC_SIZE (rev. 1.27(?) of src/sys/sys/user.h) there have been two modifications which still required to rebuild libkvm, ... Maybe many people won't use the spare entries at the end of the structure but put their additions somewhere besides some other related variables for aesthetical purposes? Which value does libkvm use? KINFO_PROC_SIZE or sizeof()? It seems it uses sizeof() since ps/top/w still work besides the warning message. -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today's panic :-)
In message [EMAIL PROTECTED] Warner Losh writes: : I note that this doesn't happen when the disks are clean on boot, but : does happen when they are dirty. The kernel is as of a cvsup 3pm MST : today. The kernel from 1am last night doesn't seem to have this : problem. Doesn't seem to have this problem that badly. I just got a very similar crash from it. Maybe I'm just lucky with the older one. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dirty buffers on reboot again?
In message [EMAIL PROTECTED] "Daniel C. Sobral" writes: : I don't have softupdates on root (but I do have elsewhere... which : reminds me I need to turn it on on a recently created partition :). It still seems to happen for me on a box that has softupdates disabled. But its frequency is far far less (1 in 20 reboots rather than 19 in 20) than the box that used to have softupdates turned on. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Panic in today current
I got a panic today on a fresh kernel... Compiled with netgraph but non of the netgraph modules. Immediately after the memory probe, a message about sequencers 0-15, then: Panic: spinlock ng_worklist not in order list Before these was WARNING: size of kinfo_proc (648) should be 644!!! -- Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic in today current
On Sat, Feb 24, 2001 at 02:33:23PM -0800, Pete Carah wrote: I got a panic today on a fresh kernel... Compiled with netgraph but non of the netgraph modules. Immediately after the memory probe, a message about sequencers 0-15, then: Panic: spinlock ng_worklist not in order list Before these was WARNING: size of kinfo_proc (648) should be 644!!! I reported this a few days ago..Julian committed something earlier today which claims to address it, I'm about to check it out. Kris PGP signature
RE: cvs commit: src/sys/kern kern_mutex.c
On 24-Feb-01 John Baldwin wrote: jhb 2001/02/24 11:36:13 PST Modified files: sys/kern kern_mutex.c Log: ... - Make the _mtx_assert() function be compiled in if INVARIANTS_SUPPORT is defined rather than if INVARIANTS is defined so that a KLD compiled with INVARIANTS that uses mtx_assert() can be used with a kernel that just has INVARIANT_SUPPORT compiled in. With this, building a kernel with INVARIANTS is back to requiring INVARIANT_SUPPORT to be present in the kernel. -- 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: Today's panic :-)
On 24-Feb-01 Julian Elischer wrote: Warner Losh wrote: I've added INVARIANTS and WITNESS to my kernel. Today I get a random panic on boot sometimes: lock order reseral (this doesn't cause the panic, but does seem to happen all the time) 1st vnode interlock last acquired @ ../../usr/ffs/ffs_fsops.c:396 2nd 0xc04837a0 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:457 3rd 0xc80b9e8c vnode interlock @ ../../kern/vfs_subr.c:1872 I keep dropping into ddb with: Don't use WITNESS_DDB and you won't drop into ddb. We're not far enough along to make that very livable yet. :( -- 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: Today's panic :-)
On 24-Feb-01 Warner Losh wrote: In message [EMAIL PROTECTED] Bruce Evans writes: : It seems to be another trap while holding sched_lock. This should be : fatal, but the problem is only detected because trap() enables : interrupts. Then an interrupt causes bad things to happen. Unfortunately, : the above omits the critical information: the instruction at sw1b+0x6b. : There is no instruction at that address here. It is apparently just an : access to a swapped-out page for the new process. I can't see how this : ever worked. The page must be faulted in, but this can't be done while : sched_lock is held (not to mention after we have committed to switching : contexts). sw1b+0x6b is ltr %si I note that this doesn't happen when the disks are clean on boot, but does happen when they are dirty. The kernel is as of a cvsup 3pm MST today. The kernel from 1am last night doesn't seem to have this problem. Other people have reported this and I can't reproduce this. The one case I managed to track down so far involved proc0 having pcb_ext bogusly set, resulting in cpu_switch() setting up a bogus GDT entry for a TSS and thus generating a GPF which is the trap you see. The enable_intr() in trap() then sends things downhill fast. I'm not sure yet why processes are having pcb_ext bogusly set. Hmm. Make sure you have rev 1.35 or later of pcb.h. Also, try build a kernel from scratch from fresh sources.. Warner -- 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 in today current
Pete Carah wrote: I got a panic today on a fresh kernel... Compiled with netgraph but non of the netgraph modules. Immediately after the memory probe, a message about sequencers 0-15, then: Panic: spinlock ng_worklist not in order list Before these was WARNING: size of kinfo_proc (648) should be 644!!! netgraph didn;t have 'WITNESS' support. I added it yesterday so maybe a resup may fix it. -- Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic in today current
Pete Carah wrote: I got a panic today on a fresh kernel... Compiled with netgraph but non of the netgraph modules. Immediately after the memory probe, a message about sequencers 0-15, then: Panic: spinlock ng_worklist not in order list argh, ignore that last message.. maybe I don;t understand how witness is supposed to work. what are your CONFIGs? I'll try duplicate them here. A Winess kernel booted fine here (dammit) Before these was WARNING: size of kinfo_proc (648) should be 644!!! that's ps having a fit about something else. -- Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic in today current
Julian Elischer wrote: Pete Carah wrote: I got a panic today on a fresh kernel... Compiled with netgraph but non of the netgraph modules. Immediately after the memory probe, a message about sequencers 0-15, then: Panic: spinlock ng_worklist not in order list The problem is probably that you put them inside of an ifdef SMP. The ifdef is there for locks that only exist for SMP. Move them after the #endif, like: /* * leaf locks */ #ifdef SMP #ifdef __i386__ "ap boot", "imen", #endif "smp rendezvous", #endif "ng_node", "ng_worklist", NULL To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic in today current
Pete Carah wrote: I got a panic today on a fresh kernel... Compiled with netgraph but non of the netgraph modules. Immediately after the memory probe, a message about sequencers 0-15, then: Panic: spinlock ng_worklist not in order list Before these was WARNING: size of kinfo_proc (648) should be 644!!! -- Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message duh. it was commented out for UP. resup to verion 1.51 Checking in kern_mutex.c; /home/ncvs/src/sys/kern/kern_mutex.c,v -- kern_mutex.c new revision: 1.51; previous revision: 1.50 done I'll pay COD for the pointy hat.. -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic in today current
Jake Burkholder wrote: Julian Elischer wrote: Pete Carah wrote: I got a panic today on a fresh kernel... Compiled with netgraph but non of the netgraph modules. Immediately after the memory probe, a message about sequencers 0-15, then: Panic: spinlock ng_worklist not in order list The problem is probably that you put them inside of an ifdef SMP. The ifdef is there for locks that only exist for SMP. already done thanks.. Move them after the #endif, like: /* * leaf locks */ #ifdef SMP #ifdef __i386__ "ap boot", "imen", #endif "smp rendezvous", #endif "ng_node", "ng_worklist", NULL -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: find / -fstype local traverses non-local filesystems
Garrett Wollman wrote: On Sat, 24 Feb 2001 17:04:44 +1030, Matthew Thyer [EMAIL PROTECTED] said: find seems to be traversing all file systems (local and non-local) but just not reporting the found file when its on a non-local filesystem. As has been discussed many times before, this is correct behavior. If you want `find' to not traverse a directory, use the `-prune' primary. Or -x to keep it on a single device/filesystem. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
