Re: missing interrupts (was Re: CURRENT is freezing again ...)
On Mon, 27 Nov 2000, Andrew Gallatin wrote: Bruce Evans writes: Possible causes of the problem: 1) isa_handle_intr() claims to send specific EOIs (0x30 | irq) but actually sends non-specific ones (0x20 | garbage). Since interrupts I think that sending non-specific EOIs is the problem. Sending specific EOIs seem to eliminate my nic timeouts and the need to manually feed an eoi to recover from a missing interrupt. My question is: how does one send a specific EOI correctly? I don't have decent documentation for this. Above, you seem to imply that 0x30 is a specific EOI. That does not seem to work for me (machine locks at boot). Linux uses 0xe0. According to some Tru64 docs I have, that means "Rotate Priority on specific EOI". According to that same documentation, 0x60 is a specific EOI. Both of these Oops, I misread the data sheet. 0x60 is correct, 0x30 is wrong. The irq number is in the lowest 3 bits. appear to work just fine. What should the alpha port use? I think it should use non-specific EOIs and send them early (when there is no ambiguity about which interrupt is being handled), as in the i386 port. Sending them late mainly gives the ICU's braindamaged interrupt priority scheme for longer than necessary. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: missing interrupts (was Re: CURRENT is freezing again ...)
In [EMAIL PROTECTED], Andrew Gallatin wrote: Bruce Evans writes: Possible causes of the problem: 1) isa_handle_intr() claims to send specific EOIs (0x30 | irq) but actually sends non-specific ones (0x20 | garbage). Since interrupts may be handled in non-LIFO order, this results in EOIs being sent for the wrong interrupts. I think this just randomizes the brokenness caused by delaying sending of EOIs. I can't see how it would result in an EOI being lost -- the right number of EOIs will have been sent after all handlers have returned. I think that sending non-specific EOIs is the problem. Sending specific EOIs seem to eliminate my nic timeouts and the need to manually feed an eoi to recover from a missing interrupt. My question is: how does one send a specific EOI correctly? I don't have decent documentation for this. Above, you seem to imply that 0x30 is a specific EOI. That does not seem to work for me (machine locks at boot). Linux uses 0xe0. According to some Tru64 docs I have, that means "Rotate Priority on specific EOI". According to that same documentation, 0x60 is a specific EOI. Both of these appear to work just fine. What should the alpha port use? My notes say: Non-specific EOI : 0x20 Specific EOI : 0x60 | IRQn EOI + rotate priority: 0xa0 EOI + select lowest priority : 0xe0 | IRQn -- Robert S. F. Drehmel [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: missing interrupts (was Re: CURRENT is freezing again ...)
Bruce Evans writes: Possible causes of the problem: 1) isa_handle_intr() claims to send specific EOIs (0x30 | irq) but actually sends non-specific ones (0x20 | garbage). Since interrupts may be handled in non-LIFO order, this results in EOIs being sent for the wrong interrupts. I think this just randomizes the brokenness caused by delaying sending of EOIs. I can't see how it would result in an EOI being lost -- the right number of EOIs will have been sent after all handlers have returned. I think that sending non-specific EOIs is the problem. Sending specific EOIs seem to eliminate my nic timeouts and the need to manually feed an eoi to recover from a missing interrupt. My question is: how does one send a specific EOI correctly? I don't have decent documentation for this. Above, you seem to imply that 0x30 is a specific EOI. That does not seem to work for me (machine locks at boot). Linux uses 0xe0. According to some Tru64 docs I have, that means "Rotate Priority on specific EOI". According to that same documentation, 0x60 is a specific EOI. Both of these appear to work just fine. What should the alpha port use? Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT is freezing again ...
On Fri, Nov 17, 2000 at 05:58:30PM -0800, Kris Kennaway wrote: On Fri, Nov 17, 2000 at 12:55:28PM +0100, Soren Schmidt wrote: I thought I was the only one, since my question on the freebsd-current mailing list went unanswered. You are _not_ alone, there has been numerous complains about this on the list, but so far they have not been taken seriously :| One of my non-SMP machines reliably wedges whenever I do heavy disk I/O. I can't break to debugger. Nov 4 15:46:41 mollari /boot/kernel/kernel: atapci0: Intel PIIX3 ATA controller port 0xffa0-0xffaf at device 7.1 on pci0 Nov 4 15:46:41 mollari /boot/kernel/kernel: ata0: at 0x1f0 irq 14 on atapci0 Nov 4 15:46:41 mollari /boot/kernel/kernel: ahc0: Adaptec 2940 Ultra SCSI adapter port 0xfc00-0xfcff mem 0xffbeb000-0xffbebfff irq 15 at device 11.0 on pci0 Nov 4 15:46:41 mollari /boot/kernel/kernel: aic7880: Wide Channel A, SCSI Id=7, 16/255 SCBs Well, adding INVARIANTS, INVARIANTS_SUPPORT, MUTEX_DEBUG and WITNESS didn't give me anything to go off. Interestingly though - I thrashed the disks for about 15 minutes to no avail before kldloading random.ko and firing up ssh, at which point it froze within a few minutes while typing. Obviously one data point isn't much to go off, but it might be somewhere to start looking. Kris PGP signature
Re: CURRENT is freezing again ...
Interestingly though - I thrashed the disks for about 15 minutes to no avail before kldloading random.ko and firing up ssh, at which point it froze within a few minutes while typing. Obviously one data point isn't much to go off, but it might be somewhere to start looking. Now that I've (almost) cleared get_cyclecounter(9) out of my TODO, I can use it, and then go about getting rid of most malloc(9)s and all TAILQs in random.ko. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT is freezing again ...
On Thu, Nov 16, 2000 at 12:20:49PM -0500, Steven E. Ames wrote: It seems to only do it SMP... the same machine built with a non-SMP kernel (same source code) runs just fine for extended periods. I have a non-SMP machine that is running a 15-nov current kernel, which freezes a few times a day. This morning I found it might coincide with the times that cvsup is running. Disabled that, I'll see if that's where the problem might show up. Freeze means: no keyboard activity possible, machine just does nothing. On Thu, 16 Nov 2000, Soren Schmidt wrote: After last cvsup my machine (Dual PIII, SMP kernel) is freezing again in 10 min after boot... You mean "is still freezing" right ? Current has been like this for longer than I care to think about, it seems those in charge doesn't take these problems seriously (enough)... I think info about where/how it freezing would be more helpful. No idea, the system just freezes, no drob to DDB no remote gdb no nothing, so its really hard to tell where... As to how, just boot current on a fairly fast machine, make a kernel and it'll hang in minutes if not less, or just leave it alone and it will hang in 10-30 mins... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Nice testing in little China... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT is freezing again ...
On Fri, 17 Nov 2000 10:30:02 -0800 (PST), John Baldwin [EMAIL PROTECTED] said:
what the WITNESS code does is perform extra checks on mutex
enter's and exit's to ensure that we aren't handling mutexes in
such a way that a deadlock is possible. Thus, it verifies that
you don't grab mutexes out of order, or that you don't grab
sleep mutexes with interrupts disabled, etc.
Is this code meaningful on UP machines? Having been a victim of these
seemingly random freezes since SMPng started, as others have noted, I
decided to compile it in earlier this week. Twice now I've been dumped
into the debugger with this output:
lock order reversal
1st dc0 last acquired @ ../../pci/if_dc.c:2717
2nd 0xc0acdb3c dc1 @ ../../pci/if_dc.c: 2717
3rd 0xc0acab3c dc0 @ ../../pci/if_dc.c: 2929
Debugger ("witness_enter")
Stopped at Debugger+0x39: movb $0, in.Debugger.639
--
Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA
[EMAIL PROTECTED] [EMAIL PROTECTED]
The atheist staring from the attic window is often nearer to God than the
believer caught up in his own false image of God. -- Martin Buber
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT is freezing again ...
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: On Fri, 17 Nov 2000 10:30:02 -0800 (PST), John Baldwin [EMAIL PROTECTED] said: what the WITNESS code does is perform extra checks on mutex enter's and exit's to ensure that we aren't handling mutexes in such a way that a deadlock is possible. Thus, it verifies that you don't grab mutexes out of order, or that you don't grab sleep mutexes with interrupts disabled, etc. Is this code meaningful on UP machines? Having been a victim of these seemingly random freezes since SMPng started, as others have noted, I decided to compile it in earlier this week. Twice now I've been dumped into the debugger with this output: lock order reversal 1st dc0 last acquired @ ../../pci/if_dc.c:2717 2nd 0xc0acdb3c dc1 @ ../../pci/if_dc.c: 2717 3rd 0xc0acab3c dc0 @ ../../pci/if_dc.c: 2929 This is on a UP machine? This looks like you're taking an interrupt on dc1 and then trying to call the dc0 start routine, which shouldn't be possible. (Unless I'm misunderstanding the witness code) What version of if_dc.c are you using? line 2929 doesn't correspond to an instance of "DC_LOCK" in my copy. -- Jonathan this should be released before anything else To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT is freezing again ...
On Sat, 18 Nov 2000 11:40:34 -0600 (CST), Jonathan Lemon [EMAIL PROTECTED] said: What version of if_dc.c 1.38 -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA [EMAIL PROTECTED] [EMAIL PROTECTED] "It's not what we don't know that hurts us, it's what we know for certain that just ain't so." -- Mark Twain To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT is freezing again ...
On Thu, 16 Nov 2000 10:42:51 PST, Alfred Perlstein wrote: I would try a new kernel, and perhaps some collabaration with John to debug these problems rather than just complaining about the situation. I see at least two experianced developers in the CC list, there's no reason for these poor bug reports. The problem with a hard lock-up out of which you can't escape into the debugger is that it makes meaningful bug reports impossible. My non-SMP workstation has exhibited apparently arbitrary lock-ups since the advent of SMPng. I thought I was the only one, since my question on the freebsd-current mailing list went unanswered. From my understanding, John's WITNESS code allows us to break into the debugger from within interrupt context. If the lock-ups are happening in there, then this may help us provide better bug reports. Oh, and a couple of deep breaths are probably in order. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT is freezing again ...
It seems Sheldon Hearn wrote: I would try a new kernel, and perhaps some collabaration with John to debug these problems rather than just complaining about the situation. I see at least two experianced developers in the CC list, there's no reason for these poor bug reports. The problem with a hard lock-up out of which you can't escape into the debugger is that it makes meaningful bug reports impossible. My non-SMP workstation has exhibited apparently arbitrary lock-ups since the advent of SMPng. I thought I was the only one, since my question on the freebsd-current mailing list went unanswered. You are _not_ alone, there has been numerous complains about this on the list, but so far they have not been taken seriously :| From my understanding, John's WITNESS code allows us to break into the debugger from within interrupt context. If the lock-ups are happening in there, then this may help us provide better bug reports. It doesn't help here at least, the machine(s) just lock up solid only reset or a powercycle can bring them back... Oh, and a couple of deep breaths are probably in order. :-) Yeah like *sigh* -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT is freezing again ...
On Fri, 17 Nov 2000 12:55:28 +0100 (CET), Soren Schmidt [EMAIL PROTECTED] said: It doesn't help here at least, the machine(s) just lock up solid only reset or a powercycle can bring them back... Same here ... as others noted, started with SMPng ... -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA [EMAIL PROTECTED] [EMAIL PROTECTED] There are things that are so serious that you can only joke about them. -- Werner Heisenberg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT is freezing again ...
In message [EMAIL PROTECTED] Sheldon Hearn writes: : The problem with a hard lock-up out of which you can't escape into the : debugger is that it makes meaningful bug reports impossible. My non-SMP : workstation has exhibited apparently arbitrary lock-ups since the advent : of SMPng. You can also short IOCHK to ground to get an NMI which kicks you into the debugger, even in an interrupt context. I have a card I built from an old multi-function card to do this. I think it is A1 and A2, but I don't have my ISA bus spec handy. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT is freezing again ...
On 17-Nov-00 Sheldon Hearn wrote: On Thu, 16 Nov 2000 10:42:51 PST, Alfred Perlstein wrote: I would try a new kernel, and perhaps some collabaration with John to debug these problems rather than just complaining about the situation. I see at least two experianced developers in the CC list, there's no reason for these poor bug reports. The problem with a hard lock-up out of which you can't escape into the debugger is that it makes meaningful bug reports impossible. My non-SMP workstation has exhibited apparently arbitrary lock-ups since the advent of SMPng. When I get a hard lock like this I usually try to see if I can reproduce it in single user mode. If I can, then I compile KTR into my kernel with the following options: KTR, KTR_EXTEND, KTR_COMPILE="0x3fff", KTR_MASK="(KTR_INTR|KTR_PROC)". Then I boot into single user (so I don't dirty filesystems), mount any needed fs's as read only if possible, and run the following command: # sysctl -w debug.ktr_verbose=1 ; command_that_makes_my_machine_go_boom And then stare at the tracing output on teh screen to see what the machine was doing when it hung. I.e., to see if it is still getting interrupts, and to see what process it died in, etc. From my understanding, John's WITNESS code allows us to break into the debugger from within interrupt context. If the lock-ups are happening in there, then this may help us provide better bug reports. Err, not quite. It's BSD/OS's WITNESS code, and what the WITNESS code does is perform extra checks on mutex enter's and exit's to ensure that we aren't handling mutexes in such a way that a deadlock is possible. Thus, it verifies that you don't grab mutexes out of order, or that you don't grab sleep mutexes with interrupts disabled, etc. -- 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: CURRENT is freezing again ...
In message [EMAIL PROTECTED], Warner Losh writes: In message [EMAIL PROTECTED] Sheldon Hearn writes: : The problem with a hard lock-up out of which you can't escape into the : debugger is that it makes meaningful bug reports impossible. My non-SMP : workstation has exhibited apparently arbitrary lock-ups since the advent : of SMPng. You can also short IOCHK to ground to get an NMI which kicks you into the debugger, even in an interrupt context. Bad news for you warner: On a too large sample of my newer motherboards this doesn't work anymore :-( -- 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
Re: CURRENT is freezing again ...
In message 25636.974487067@critter Poul-Henning Kamp writes: : In message [EMAIL PROTECTED], Warner Losh writes: : In message [EMAIL PROTECTED] Sheldon Hearn writes: : : The problem with a hard lock-up out of which you can't escape into the : : debugger is that it makes meaningful bug reports impossible. My non-SMP : : workstation has exhibited apparently arbitrary lock-ups since the advent : : of SMPng. : : You can also short IOCHK to ground to get an NMI which kicks you into : the debugger, even in an interrupt context. : : Bad news for you warner: On a too large sample of my newer : motherboards this doesn't work anymore :-( There's also a pci signal that you can either pull up or pull down that's supposed to give you the same results. I've never really needed to know it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT is freezing again ...
On Fri, Nov 17, 2000 at 12:55:28PM +0100, Soren Schmidt wrote: I thought I was the only one, since my question on the freebsd-current mailing list went unanswered. You are _not_ alone, there has been numerous complains about this on the list, but so far they have not been taken seriously :| One of my non-SMP machines reliably wedges whenever I do heavy disk I/O. I can't break to debugger. Nov 4 15:46:41 mollari /boot/kernel/kernel: atapci0: Intel PIIX3 ATA controller port 0xffa0-0xffaf at device 7.1 on pci0 Nov 4 15:46:41 mollari /boot/kernel/kernel: ata0: at 0x1f0 irq 14 on atapci0 Nov 4 15:46:41 mollari /boot/kernel/kernel: ahc0: Adaptec 2940 Ultra SCSI adapter port 0xfc00-0xfcff mem 0xffbeb000-0xffbebfff irq 15 at device 11.0 on pci0 Nov 4 15:46:41 mollari /boot/kernel/kernel: aic7880: Wide Channel A, SCSI Id=7, 16/255 SCBs Kris PGP signature
Re: CURRENT is freezing again ...
: You can also short IOCHK to ground to get an NMI which kicks you into : the debugger, even in an interrupt context. : : Bad news for you warner: On a too large sample of my newer : motherboards this doesn't work anymore :-( There's also a pci signal that you can either pull up or pull down that's supposed to give you the same results. I've never really needed to know it. SERR behaviour is programmable and there is no standard for it. 8( -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT is freezing again ...
On Thu, 16 Nov 2000, Soren Schmidt wrote: After last cvsup my machine (Dual PIII, SMP kernel) is freezing again in 10 min after boot... You mean "is still freezing" right ? Current has been like this for longer than I care to think about, it seems those in charge doesn't take these problems seriously (enough)... I think info about where/how it freezing would be more helpful. I've started doing development on -stable instead, it goes nowhere on -current shurg - works fine for me even with my new evil hacks :) -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT is freezing again ...
It seems to only do it SMP... the same machine built with a non-SMP kernel (same source code) runs just fine for extended periods. -Steve - Original Message - From: "Soren Schmidt" [EMAIL PROTECTED] To: "Boris Popov" [EMAIL PROTECTED] Cc: "Valentin Chopov" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, November 16, 2000 12:17 PM Subject: Re: CURRENT is freezing again ... It seems Boris Popov wrote: On Thu, 16 Nov 2000, Soren Schmidt wrote: After last cvsup my machine (Dual PIII, SMP kernel) is freezing again in 10 min after boot... You mean "is still freezing" right ? Current has been like this for longer than I care to think about, it seems those in charge doesn't take these problems seriously (enough)... I think info about where/how it freezing would be more helpful. No idea, the system just freezes, no drob to DDB no remote gdb no nothing, so its really hard to tell where... As to how, just boot current on a fairly fast machine, make a kernel and it'll hang in minutes if not less, or just leave it alone and it will hang in 10-30 mins... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT is freezing again ...
It seems Boris Popov wrote: On Thu, 16 Nov 2000, Soren Schmidt wrote: After last cvsup my machine (Dual PIII, SMP kernel) is freezing again in 10 min after boot... You mean "is still freezing" right ? Current has been like this for longer than I care to think about, it seems those in charge doesn't take these problems seriously (enough)... I think info about where/how it freezing would be more helpful. No idea, the system just freezes, no drob to DDB no remote gdb no nothing, so its really hard to tell where... As to how, just boot current on a fairly fast machine, make a kernel and it'll hang in minutes if not less, or just leave it alone and it will hang in 10-30 mins... I have the same problem on a dual PII 400mhz. I haven't tried to remove the SMP support, but I have not too much time to cvsup and to make anything else. I'll try to boot the GENERIC (damn !%! , I always repeat to myself that is a good habits to compile the GENERIC too after updates... but I never do... :-( ) -- Regards... Gianmarco "Unix expert since yesterday" http://www.giovannelli.it To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT is freezing again ...
* Steven E. Ames [EMAIL PROTECTED] [001116 09:27] wrote: It seems to only do it SMP... the same machine built with a non-SMP kernel (same source code) runs just fine for extended periods. John just checked in some code last night that may address your problems. I would try a new kernel, and perhaps some collabaration with John to debug these problems rather than just complaining about the situation. I see at least two experianced developers in the CC list, there's no reason for these poor bug reports. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: CURRENT is freezing again ...
On 16-Nov-00 Valentin Chopov wrote: Hi, After last cvsup my machine (Dual PIII, SMP kernel) is freezing again in 10 min after boot... Thanks, Val Two questions: 1) What revision of sys/kern/kern_synch.c do you have? I fixed several things yesterday, and the latest version is 1.108. 2) If you do have the latest version, have you compiled a kernel with WITNESS, INVARIANTS, and INVARIANT_SUPPORT to see how it runs? Also, I have noticed that occasionally on my SMP boxes the console seems to lose itself. By lose itself, I mean that all output stops, and it doesn't process any input. If I hit Ctrl-Alt-Backspace to break into the debugger, it suddenly catches up and processes all pending events before dropping into teh debugger, but hangs again when I continue from ddb. However, the rest of hte machine works fine during this time. I can ssh in, build kernels, reboot, etc. without any problem. -- 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: CURRENT is freezing again ...
It seems John Baldwin wrote: 1) What revision of sys/kern/kern_synch.c do you have? I fixed several things yesterday, and the latest version is 1.108. 1.108 2) If you do have the latest version, have you compiled a kernel with WITNESS, INVARIANTS, and INVARIANT_SUPPORT to see how it runs? Have those in too... It still cant compile a kernel, it hangs itself in ~30 secs, no messages, no hints, no nothing, the machine just locks up solid as usual.. Mind you the same machines run 4.2 and PRE_SMPNG without a hitch... Also, I have noticed that occasionally on my SMP boxes the console seems to lose itself. By lose itself, I mean that all output stops, and it doesn't process any input. If I hit Ctrl-Alt-Backspace to break into the debugger, it suddenly catches up and processes all pending events before dropping into teh debugger, but hangs again when I continue from ddb. However, the rest of hte machine works fine during this time. I can ssh in, build kernels, reboot, etc. without any problem. It has been like this almost since the SMPNG stuff vent in, at least on all my -current machines... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT is freezing again ...
On Thu, Nov 16, 2000 at 10:27:39PM +0100, Soren Schmidt scribbled: | It seems John Baldwin wrote: | | 1) What revision of sys/kern/kern_synch.c do you have? I fixed several things | yesterday, and the latest version is 1.108. | | 1.108 | | 2) If you do have the latest version, have you compiled a kernel with WITNESS, | INVARIANTS, and INVARIANT_SUPPORT to see how it runs? | | Have those in too... | | It still cant compile a kernel, it hangs itself in ~30 secs, no messages, | no hints, no nothing, the machine just locks up solid as usual.. | | Mind you the same machines run 4.2 and PRE_SMPNG without a hitch... | | Also, I have noticed that occasionally on my SMP boxes the console seems to | lose itself. By lose itself, I mean that all output stops, and it doesn't | process any input. If I hit Ctrl-Alt-Backspace to break into the debugger, it | suddenly catches up and processes all pending events before dropping into teh | debugger, but hangs again when I continue from ddb. However, the rest of hte | machine works fine during this time. I can ssh in, build kernels, reboot, etc. | without any problem. | | It has been like this almost since the SMPNG stuff vent in, at least on all my | -current machines... I had those problems too a while ago on a UP p3-650 laptop. Finally I just newfs'ed the machine and installed the 20001028 snapshot, then cvsupp'ed to 20001122. The laptop now works well. What I saw was processes forking and forking again until the machine runs out of memory and swap. I think it may be some old libraries left over from upgrades and make world. -- +--+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
