HEADS-UP: await/asleep removal imminent
Please trim cc's as appropriate. I have a patch here that removes await/asleep from the kernel API. http://people.freebsd.org/~alfred/noasleep.diff Matt Dillon implemented alseep/await quite some time ago and the only thing that's using it is ata. In order to clean up some of the schduler and vm system I'm removing support for it. Peter Wemm and I suspect that ata doesn't need it. Right now I'm running several make -j128 buildworlds and buildkernels with this patch to catch any ata problems. Now would be a good time to test this delta for stability reasons. I plan on applying the delta within a few days. thanks, -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
It seems Alfred Perlstein wrote: Please trim cc's as appropriate. I have a patch here that removes await/asleep from the kernel API. http://people.freebsd.org/~alfred/noasleep.diff Matt Dillon implemented alseep/await quite some time ago and the only thing that's using it is ata. In order to clean up some of the schduler and vm system I'm removing support for it. Peter Wemm and I suspect that ata doesn't need it. Right now I'm running several make -j128 buildworlds and buildkernels with this patch to catch any ata problems. I'll commit the ata part as soon as I have it tested here -Sren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP! New netgraph code coming
Alfred Perlstein [EMAIL PROTECTED] writes: This ought to be documented. A good start would be to add example of MODULE_VERSION and MODULE_DEPEND usage to one of the templates in /usr/share/examples/kld/. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VXA tape drive
On Mon, Jan 15, 2001 at 12:49:29PM -0600, David W. Chapman Jr. wrote: I checked in current with little luck. Does -current support VXA-1 tape drives by Ecrix. The site claims that freebsd does, but the only response by someone that has one says that it won't successfully backup. I've been using an external VXA-1 drive since October 1999 (FreeBSD 3.3 or so). It is currently attached to a FreeBSD 4.1 machine. I really love it. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
WANTED: testers with VIA 82C686B southbridges!!
I've committed support for the VIA 82c686B southbridge, but I lack testing with an ATA100 drive to make sure it works as it should. Could somebody try the following if they have this HW setup: for i in 1 2 3 4 do dd if=/dev/adN of=/dev/null bs=512k count=1 # N is you drive number done and mail me the resulting output together with a dmesg copy ? Thanks! -Sren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fan speed control sony vaio lx800 slimtop
I'm giving up on turning down the slimtop fan for now, the only way I can think of to figure out how Sony is turning down the fan is to boot windows, single step through the installation of the device drivers until I know which one is doing it, and then disassemble it to see what they're up to. If someone has any other ideas let me know. I might hook a scope up to the fan and boot windows just to see if it simply turning the fan down or is varying it. Maybe I'll add a voltage regulator and a few bits of control from the unused printer (it isn't run off the MB) and vary the fan speed brute force. I asked Sony support about the fan issue, they promptly replied that running the fan at high continuosly is fine, that no additional information is available, and that they will "record my interest in alternate operating systems". At least they have a polite way of saying they support nothing but Windows. So I'm going to roll this system back to 4.2 stable and start using it for work. If anyone wants me to try anything out with -current or ACPI then holler today. Two additional ACPI-APM things I did notice: 1. Putting APM into the config caused the keyboard switch to start working to turn the machine on. I'd taken it out at someones suggestion. This is weird, I can only guess APM does something as the machine powers off that ACPI doesn't. 2. Using APM to suspend the machine causes the LED on the power switch to turn amber, using "acpiconf -s 1" doesn't, the machine suspends but the LED stays green. If anyone has any little snippet they want me to try before going back to stable let me know. Anyway, if anyone buys one of these things then rubber bumpers on the base and Dynamat lining the plastic case makes it as quiet as a "normal" computer plus gives it a real solid feel. Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Atomic breakage?
On Wed, 17 Jan 2001 14:26:54 +1100, Peter Jeremy [EMAIL PROTECTED] said: To support multiple masters, you need proper locks. On older processors, yes. On processors with the CX8 feature bit set, you can do it without any sort of locking (indeed, this is a primitive that semaphores can be built upon). Consider the following: atomic_increment: ; prologue ; get EA into %esi movl (%esi), %eax movl 4(%esi), %edx 1: movl %eax, %ebx movl %edx, %ecx incl %ebx adcl $0, %ecx cmpxchg8b (%esi); generates a locked bus cycle jne 1 ; epilogue On pre-Pentium processors (which lack the CX8 feature) this sort of sequence is impossible. OTOH, I don't think SMP works on any pre-Pentium processor, so again this degenerates to: pushfl cli incl (%esi) adcl $0, 4(%esi) popfl ...in the non-SMP case. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
It seems Alfred Perlstein wrote:
I have a patch here that removes await/asleep from the kernel API.
http://people.freebsd.org/~alfred/noasleep.diff
Matt Dillon implemented alseep/await quite some time ago and the
only thing that's using it is ata. In order to clean up some of
the schduler and vm system I'm removing support for it.
Peter Wemm and I suspect that ata doesn't need it. Right now I'm
running several make -j128 buildworlds and buildkernels with this
patch to catch any ata problems.
U...
It seems to me from reading the man page for asleep/await that
they have significant utility, and that the real issue would be one of
code not using them, especially as people work to remove the Giant
lock for SMP.
Or is the discussion in the man page wrong in some way?
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Atomic breakage?
On Tue, 16 Jan 2001 19:10:10 -0800, Alfred Perlstein [EMAIL PROTECTED] said: Just wondering, can't you use 'LOCK addl' and then use 'LOCK addc'? add longword, add longword with carry? I know it would be pretty ugly, but it should work, no? The two bus cycles are independent, so there is a race condition. OTOH, it's a fairly *unlikely* race condition, and the worst thing that can happen is statistics that are obviously off by four billion. (The race only occurs when there is a carry out of the low-order longword, which is to say, once in every 2**32 operations.) -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Atomic breakage?
On 17-Jan-01 Garrett Wollman wrote: On Wed, 17 Jan 2001 14:26:54 +1100, Peter Jeremy [EMAIL PROTECTED] said: To support multiple masters, you need proper locks. On older processors, yes. On processors with the CX8 feature bit set, you can do it without any sort of locking (indeed, this is a primitive that semaphores can be built upon). Consider the following: atomic_increment: ; prologue ; get EA into %esi movl (%esi), %eax movl 4(%esi), %edx 1:movl %eax, %ebx movl %edx, %ecx incl %ebx adcl $0, %ecx cmpxchg8b (%esi); generates a locked bus cycle jne 1 ; epilogue On pre-Pentium processors (which lack the CX8 feature) this sort of sequence is impossible. OTOH, I don't think SMP works on any pre-Pentium processor, so again this degenerates to: pushfl cli incl (%esi) adcl $0, 4(%esi) popfl ...in the non-SMP case. Early Pentiums (= P90) don't support CX8 or so I've heard, which make this slightly more complicated, as for a pentium we would have to use a function pointer that we setup during probe. Also, during a SMP boot we would have to panic if CX8 wasn't enabled on all CPU's. -GAWollman -- 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: HEADSUP! New netgraph code coming
* Dag-Erling Smorgrav [EMAIL PROTECTED] [010117 04:27] wrote: Alfred Perlstein [EMAIL PROTECTED] writes: This ought to be documented. A good start would be to add example of MODULE_VERSION and MODULE_DEPEND usage to one of the templates in /usr/share/examples/kld/. Since I have no clue as to how they work, it'll have to wait until someone who knows how it works does it or I have the time to UTSL. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP! New netgraph code coming
Alfred Perlstein [EMAIL PROTECTED] writes: Since I have no clue as to how they work, it'll have to wait until someone who knows how it works does it or I have the time to UTSL. MODULE_VERSION(module, version); module is the name of your module. version is the integer version number of your module. MODULE_DEPEND(module, mdepend, vmin, vpref, vmax); mdpepend is the name of the module your module depends on. vmin, vpref, vmac are the minimum, maximum and preferred versions of the module your module depends on. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
* Randell Jesup [EMAIL PROTECTED] [010117 08:14] wrote: It seems Alfred Perlstein wrote: I have a patch here that removes await/asleep from the kernel API. http://people.freebsd.org/~alfred/noasleep.diff Matt Dillon implemented alseep/await quite some time ago and the only thing that's using it is ata. In order to clean up some of the schduler and vm system I'm removing support for it. Peter Wemm and I suspect that ata doesn't need it. Right now I'm running several make -j128 buildworlds and buildkernels with this patch to catch any ata problems. U... It seems to me from reading the man page for asleep/await that they have significant utility, and that the real issue would be one of code not using them, especially as people work to remove the Giant lock for SMP. Or is the discussion in the man page wrong in some way? The manpage is correct, but we've yet to see it used properly in the code with the exception of ata, and even with ata we're not sure if it's needed. Basically the idea is that at a certain depth into the kernel you start using the M_AWAIT parameter when requesting certain resources. Since that removes the possiblity of blocking you can feel safe holding a mutex over these lower parts of the code, then only releasing your mutex later. If a resource shortage is detected then you can call await and retry later. 1) from sleep(9): to actually wait for the previously queued wait condition. If asleep() is called several times, only the most recent call is effective. asleep() may be called with an ident value of NULL to remove any previ- ously queued condition. Basically, there's a chance you may clobber previous calls to asleep, this is somewhat unlikely since most shortages or blocking when some 'NOBLOCK' flag is passed in should immediately return. Somewhat of a concern, but it really is unlikely to be a problem. 2) most things you'd use mawait for would be under a lock already, since it's under a lock, you must context switch anyway, there's no "optimized out" sleep, because first the interrupt will block on your mutex, then you'll get to run, when you drop your mutex the interrupt will then run. If you do this with msleep or masleep the effect is the same. 3) no one uses it! :) 4) most anything you need asleep for could probably be done with mutex/cv's. I'm not going to axe it for a few days, this is a really amazing API that Matt added, the problem is utility and useage over code complexity. It's just a proposal. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Atomic breakage?
In [EMAIL PROTECTED], John Baldwin wrote: Early Pentiums (= P90) don't support CX8 or so I've heard, which make this slightly more complicated, as for a pentium we would have to use a function pointer that we setup during probe. Also, during a SMP boot we would have to panic if CX8 wasn't enabled on all CPU's. P75 (stepping 5): FPU,VME,DE,PSE,TSC,MSR,MCE,CX8 cmpxchg8 was actually introduced with the Pentium processors, as Mr. Wollman already wrote. -- Robert S. F. Drehmel [EMAIL PROTECTED] Real hackers run -current from punchcards. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
It seems Alfred Perlstein wrote: Peter Wemm and I suspect that ata doesn't need it. Right now I'm running several make -j128 buildworlds and buildkernels with this patch to catch any ata problems. U... It seems to me from reading the man page for asleep/await that they have significant utility, and that the real issue would be one of code not using them, especially as people work to remove the Giant lock for SMP. Or is the discussion in the man page wrong in some way? The manpage is correct, but we've yet to see it used properly in the code with the exception of ata, and even with ata we're not sure if it's needed. Uhm, well I tried removing it here, and now -current (on SMP HW) fails in new "interesting" ways. The problem here is that -current is not stable on SMP HW so the question is if this change in behavior is to the better or to the worse... I suggest creative manpower is used to stabilize -current, instead of fine trimming which API's should stay or not... -Sren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
* Alfred Perlstein [EMAIL PROTECTED] [010117 09:24] wrote:
I'm not going to axe it for a few days, this is a really amazing
API that Matt added, the problem is utility and useage over code
complexity.
It's just a proposal.
I found several places where it may be useful, but I'm not sure if the
benefits outweigh the gains.
In a copy of the tree I've locked down the socket layer (not the entire
stack, just sockets :) ) there's code like this:
SOCKBUF_UNLOCK(so-so_snd, 0);
if (top == 0) {
MGETHDR(m, M_TRYWAIT, MT_DATA);
if (m == NULL) {
error = ENOBUFS;
SOCKBUF_LOCK(so-so_snd, 0);
goto release;
}
mlen = MHLEN;
...
SOCKBUF_LOCK(so-so_snd, 0); /* XXX */
The lock must be unwound becasue we're calling MGETHDR with M_TRYWAIT.
If wae used M_TRY'A'WAIT the code would probably look something like
this:
/* SOCKBUF_UNLOCK(so-so_snd, 0); */
again:
if (top == 0) {
MGETHDR(m, M_TRYWAIT, MT_DATA);
if (m == NULL) {
error = mawait(so-so_snd.sb_mtx, -1, -1);
if (error) {
if (error == EWOULDBLOCK)
error = ENOBUFS;
goto release;
}
goto again;
/* SOCKBUF_LOCK(so-so_snd, 0); */
}
mlen = MHLEN;
...
/* SOCKBUF_LOCK(so-so_snd, 0); */ /* XXX */
Which means we don't have to drop the lock over the socket unless
we'd block on allocation.
Matt, is this what you intended for it to do? So far I've only
seen it used to avoid races, but not to optimize out mutex
aquire/release.
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
* Soren Schmidt [EMAIL PROTECTED] [010117 10:02] wrote: It seems Alfred Perlstein wrote: Peter Wemm and I suspect that ata doesn't need it. Right now I'm running several make -j128 buildworlds and buildkernels with this patch to catch any ata problems. U... It seems to me from reading the man page for asleep/await that they have significant utility, and that the real issue would be one of code not using them, especially as people work to remove the Giant lock for SMP. Or is the discussion in the man page wrong in some way? The manpage is correct, but we've yet to see it used properly in the code with the exception of ata, and even with ata we're not sure if it's needed. Uhm, well I tried removing it here, and now -current (on SMP HW) fails in new "interesting" ways. The problem here is that -current is not stable on SMP HW so the question is if this change in behavior is to the better or to the worse... I suggest creative manpower is used to stabilize -current, instead of fine trimming which API's should stay or not... I started a loop of make -j128 buildworld and buildkernel last night, I still haven't seen anything odd happen on my hardware. You and Poul-Henning have to figure out what's going on, no one else is able to reproduce this instability you're talking about. There has to be a way for you guys to get us some reasonable tracebacks or diagnostics instead of just saying "it's broke". Perhaps you can explain how you're able to trigger this instability with a test script? Poul-Henning told me he just needed to do a make -j256 world, I did 10 of them without a problem... I'd also like to see what hardware you guys are running on and what kernel config. I'm pretty sure that running with a weird value for HZ causes lockups on -stable, dunno about current. Basically if you're expecting me or the SMP team to figure out what's going on without more info, you're pretty much out of luck. ...wondering if the box Paul Saab gave me is actually SMP... :) -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
Perhaps you can explain how you're able to trigger this instability with a test script? Poul-Henning told me he just needed to do a make -j256 world, I did 10 of them without a problem... Then you misunderstood me, I don't have anything in the dept of SMP hw which can trigger it. -- 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: Atomic breakage?
On 17-Jan-01 Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Robert Drehmel writes: In [EMAIL PROTECTED], John Baldwin wrote: Early Pentiums (= P90) don't support CX8 or so I've heard, which make this slightly more complicated, as for a pentium we would have to use a function pointer that we setup during probe. Also, during a SMP boot we would have to panic if CX8 wasn't enabled on all CPU's. P75 (stepping 5): FPU,VME,DE,PSE,TSC,MSR,MCE,CX8 cmpxchg8 was actually introduced with the Pentium processors, as Mr. Wollman already wrote. Either way, it's precense should be determined by looking at the CPUID feature bit. It's the only reliable way. It's expensive though. Ok, after some digging I found out what this particular person was referring to: on Pentiums with stepping 0xc, a cmpxchg8b that crosses a page boundary triggers an illegel opcode fault rather than a page fault if the second page is missing. Woo. :) So as long as we keep all atomically-accessed 64-bit integers within a single page we should be fine for CX8 on all pentiums should we even want 64-bit atomic ops. -- 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: Atomic breakage?
On Wed, 17 Jan 2001 10:28:03 -0800 (PST), John Baldwin [EMAIL PROTECTED] said: person was referring to: on Pentiums with stepping 0xc, a cmpxchg8b that crosses a page boundary triggers an illegel opcode fault rather than a page fault if the second page is missing. This is (part of) the famous `F00F bug'. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
It seems Alfred Perlstein wrote: I suggest creative manpower is used to stabilize -current, instead of fine trimming which API's should stay or not... I started a loop of make -j128 buildworld and buildkernel last night, I still haven't seen anything odd happen on my hardware. You and Poul-Henning have to figure out what's going on, no one else is able to reproduce this instability you're talking about. Oohh you dont read the mailing lists then, there has been plenty of reports of hanging -current boxen since SMPng... There has to be a way for you guys to get us some reasonable tracebacks or diagnostics instead of just saying "it's broke". Its close to impossible, the two symptoms I see here are either spontanous reboots, or solid hangs where only a reset can get you out, so I cant say much other than "it's broke". Perhaps you can explain how you're able to trigger this instability with a test script? Poul-Henning told me he just needed to do a make -j256 world, I did 10 of them without a problem... Hmm, with a -current kernel from today 1200 CET i just need to do a make depend on a GENERIC kernel, and wham it locks up. I'd also like to see what hardware you guys are running on and what kernel config. I'm pretty sure that running with a weird value for HZ causes lockups on -stable, dunno about current. Nothing special, GENERIC kernel with SMP defined will do nicely, running without SMP improves matters but on the fastet machine I'm still getting lockups, but they are rare... Hardware it hangs on here include: 2*PPro@200 192MB FX chipset ATA disks on onboard controller (PIIX3) 2*PII@350 512MB BX chipset SCSI disks on NCR controller 2*PIII@1G 512MB ServerWorks chipset ATA disks on onboard + HPT controller. It seems the faster the machine the faster the lockup/hang.. Need I mention that they all work just fine(tm) under -stable and -current back on PRE_SMPNG... So, we (phk I) are trying to figure out what is going on, but there is little to go on but hunch... So there is nothing special to it guys, you just have to try.. Oh btw using a ccd/vinum/ATA-raid thingy makes the problem worse, probably due to the higher interrupt rates. Basically if you're expecting me or the SMP team to figure out what's going on without more info, you're pretty much out of luck. See above, not really possible, we have been trying to find some (affordable) HW that could be used to preserve a log over a boot, but so far I havn't been able to find anything that works, and is fast enough to not effect the system too much... ...wondering if the box Paul Saab gave me is actually SMP... :) Yup, that would explain things :) -Sren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
* Poul-Henning Kamp [EMAIL PROTECTED] [010117 10:25] wrote: Perhaps you can explain how you're able to trigger this instability with a test script? Poul-Henning told me he just needed to do a make -j256 world, I did 10 of them without a problem... Then you misunderstood me, I don't have anything in the dept of SMP hw which can trigger it. If you could be more vague it would assist me greatly in figuring out what's broken. /sarcasm thanks, -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
* Soren Schmidt [EMAIL PROTECTED] [010117 10:43] wrote: It seems Alfred Perlstein wrote: I suggest creative manpower is used to stabilize -current, instead of fine trimming which API's should stay or not... I started a loop of make -j128 buildworld and buildkernel last night, I still haven't seen anything odd happen on my hardware. You and Poul-Henning have to figure out what's going on, no one else is able to reproduce this instability you're talking about. Oohh you dont read the mailing lists then, there has been plenty of reports of hanging -current boxen since SMPng... Yes, but none with anything useful. :( There has to be a way for you guys to get us some reasonable tracebacks or diagnostics instead of just saying "it's broke". Its close to impossible, the two symptoms I see here are either spontanous reboots, or solid hangs where only a reset can get you out, so I cant say much other than "it's broke". You probably have a much better understanding of low level programming than I do, you _should_ be able to figure out what's going on. Perhaps you can explain how you're able to trigger this instability with a test script? Poul-Henning told me he just needed to do a make -j256 world, I did 10 of them without a problem... Hmm, with a -current kernel from today 1200 CET i just need to do a make depend on a GENERIC kernel, and wham it locks up. Odd, doesn't hang for me. I'd also like to see what hardware you guys are running on and what kernel config. I'm pretty sure that running with a weird value for HZ causes lockups on -stable, dunno about current. Nothing special, GENERIC kernel with SMP defined will do nicely, running without SMP improves matters but on the fastet machine I'm still getting lockups, but they are rare... Hardware it hangs on here include: 2*PPro@200 192MB FX chipset ATA disks on onboard controller (PIIX3) 2*PII@350 512MB BX chipset SCSI disks on NCR controller 2*PIII@1G 512MB ServerWorks chipset ATA disks on onboard + HPT controller. It seems the faster the machine the faster the lockup/hang.. Need I mention that they all work just fine(tm) under -stable and -current back on PRE_SMPNG... So, we (phk I) are trying to figure out what is going on, but there is little to go on but hunch... So there is nothing special to it guys, you just have to try.. Oh btw using a ccd/vinum/ATA-raid thingy makes the problem worse, probably due to the higher interrupt rates. I will try stacking a vinum over vn striped setup later tonight to see if this still locks up. You're still not telling me what combination of vn/vinum does this, so I guess I'll have to stumble around in the dark for a bit until I find the magic combination to find the Danish panic/lockup? I think phk just told me that you need a UP kernel to find this, but he's being pretty vague about it so I don't know. Basically if you're expecting me or the SMP team to figure out what's going on without more info, you're pretty much out of luck. See above, not really possible, we have been trying to find some (affordable) HW that could be used to preserve a log over a boot, but so far I havn't been able to find anything that works, and is fast enough to not effect the system too much... ...wondering if the box Paul Saab gave me is actually SMP... :) Yup, that would explain things :) Well, I do see processes migrating from CPU to CPU and there's the dmesg: FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 4, version: 0x000f0011, at 0xfec0 io1 (APIC): apic id: 5, version: 0x000f0011, at 0xfec01000 SMP: AP CPU #1 Launched! SMP: CPU1 apic_initialize(): lint0: 0x00010700 lint1: 0x00010400 TPR: 0x0010 SVR: 0x01ff start_init: trying /sbin/init Dual 750mhz, 1GB RAM, atapci0: ServerWorks ROSB4 ATA33 controller dual disks: ad0: IBM-DTLA-307030/TX4OA50C ATA-5 disk at ata0-master -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
On 17-Jan-01 Soren Schmidt wrote: Nothing special, GENERIC kernel with SMP defined will do nicely, running without SMP improves matters but on the fastet machine I'm still getting lockups, but they are rare... AHA! Useful info!! GENERIC is quite close to bloated, so the fact that it is GENERIC + SMP maybe an edge case. I'll try and test this out now that you have actually provided some useful info. :-P If you want a stable box, try trimming the kernel config down to what you need. -- 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: HEADS-UP: await/asleep removal imminent
On 17-Jan-01 Poul-Henning Kamp wrote: Perhaps you can explain how you're able to trigger this instability with a test script? Poul-Henning told me he just needed to do a make -j256 world, I did 10 of them without a problem... Then you misunderstood me, I don't have anything in the dept of SMP hw which can trigger it. Ok, what _does_ trigger this then? And what kernel config are you using: GENERIC? GENERIC is rather plagued with problems right now due to its bloated size. There have been reports of people not being able to boot a freshly installed system because of the kernel bloat, so you really probably want to be using a custom kernel until that bug is found and uncovered. -- 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: HEADS-UP: await/asleep removal imminent
It seems Alfred Perlstein wrote: You and Poul-Henning have to figure out what's going on, no one else is able to reproduce this instability you're talking about. Oohh you dont read the mailing lists then, there has been plenty of reports of hanging -current boxen since SMPng... Yes, but none with anything useful. :( Check, but thats because the breakage is the way it is, there *IS* no useful info to pass on, other than it locks up, is that so hard to understand ?? There has to be a way for you guys to get us some reasonable tracebacks or diagnostics instead of just saying "it's broke". Its close to impossible, the two symptoms I see here are either spontanous reboots, or solid hangs where only a reset can get you out, so I cant say much other than "it's broke". You probably have a much better understanding of low level programming than I do, you _should_ be able to figure out what's going on. Ohh, thanks for the roses, but I havn't been following the SMP work that closely I thought it was in good hands, thats why I have told you guys that its broken for the last couble of months :) So there is nothing special to it guys, you just have to try.. Oh btw using a ccd/vinum/ATA-raid thingy makes the problem worse, probably due to the higher interrupt rates. I will try stacking a vinum over vn striped setup later tonight to see if this still locks up. You're still not telling me what combination of vn/vinum does this, so I guess I'll have to stumble around in the dark for a bit until I find the magic combination to find the Danish panic/lockup? I didn't mention vn above, I use the ata-raid thingy with src obj put on two striped disks each. The main point here being that this changes the way IO's are done... I think phk just told me that you need a UP kernel to find this, but he's being pretty vague about it so I don't know. You need sleep :) I said that SMP lockups quickly, UP runs pretty well and only hangs on rare occasions... -Sren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
:* Alfred Perlstein [EMAIL PROTECTED] [010117 09:24] wrote:
:
: I'm not going to axe it for a few days, this is a really amazing
: API that Matt added, the problem is utility and useage over code
: complexity.
:
: It's just a proposal.
:
:I found several places where it may be useful, but I'm not sure if the
:benefits outweigh the gains.
:...
:
:The lock must be unwound becasue we're calling MGETHDR with M_TRYWAIT.
:If wae used M_TRY'A'WAIT the code would probably look something like
:this:
The basic premis of using asleep()/await() is to allow you to
propogate a 'blocking condition' back up to a higher level rather
then blocking deep in side the kernel.
The original reasoning was to deal with memory allocation blockages.
For example, lets say you have three subsystem layers calling each
other. The top layer wishes to implement a non-blocking API but the
bottom layer might do an allocation that could block.
The bottom layer could do a non-blocking allocation and return NULL,
but how does the top layer (or an even higher layer) know when to try
again?
The original idea with asleep()/await() was for the bottom layer to
call asleep() on the resource that would block and then return NULL.
NULL would tell the higher layer(s) that someone down below couldn't
get some resource and that an asleep() has been setup.
The higher layers can then decide what to do with the situation.. they
can abort the operation entirely, they can do the blocking (await() call)
themselves, or they can propogate the condition to their own callers.
This way you can hold more then one lock (now mutex) through a number
of program layers without having to worry about them blocking on you.
--
For the c urrent SMP system, asleep()/await() could be used to deal with
complex situations where you (A) do not want to release a mutex through
a call to another subsystem (like the memory allocator), or (B) do not
know if the code calling you is already holding some mutex X and you
want to hold mutex Y while you make a call to another subsystem.
So, in that regard, you example:
:/* SOCKBUF_UNLOCK(so-so_snd, 0); */
:again:
:if (top == 0) {
:MGETHDR(m, M_TRYWAIT, MT_DATA);
:if (m == NULL) {
:error = mawait(so-so_snd.sb_mtx, -1, -1);
:if (error) {
: if (error == EWOULDBLOCK)
: error = ENOBUFS;
: goto release;
:}
:goto again;
:/* SOCKBUF_LOCK(so-so_snd, 0); */
:}
:mlen = MHLEN;
:...
:/* SOCKBUF_LOCK(so-so_snd, 0); */ /* XXX */
:
:Which means we don't have to drop the lock over the socket unless
:we'd block on allocation.
Works exactly as I originally intended.
:Matt, is this what you intended for it to do? So far I've only
:seen it used to avoid races, but not to optimize out mutex
:aquire/release.
:
:--
:-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
I've never liked the BSDI mutex rules, because subsystems have to have
major knowledge as to how other systems operate (in reagrds to whether
they can block or not), and the callee must have intimate knowledge of
the callers to know that it can hold a mutex and that be the only mutex
it is holding.
This makes for extremely fragile and complex coding.
So, this said... I'm still on the fence as to whether await()/asleep()
can be used effectively. As you said, there are not too many cases
at the moment and await()/asleep() does introduce significant code
complexity to the scheduler, and for it to really shine it needs to be
optimized to not require any sort of mutex at all in the calls to
asleep().
In order to get rid of the overhead, asleep() needs to simply initialize
the curproc fields and not try to actually queue the process to the
sleep queue. Right now asleep() queues the process to the sleep queue
(see kern/kern_synch.c) in order to support the ability for the system
to asynchronously 'wake the process up again' before it actually goes to
sleep (which causes the later await() to become a NOP). i.e. the
situation that caused the potential blockage might be resolved before
the process has a chance to sleep. Traditionally we have used SPL levels
(and now mutexes) to prevent the possibility of a condition being
satisfied between the test and the tsleep().
Proposal
Revamp asleep/await to be based on state variables rather then
tsleep's traditionaln 'fake' addresses. Rather then
have a traditional sleep/wakeup we instead have a state variable that
asleep/await operate on. For example lets say we have a memory allocator.
When the memory
Re: HEADS-UP: await/asleep removal imminent
It seems John Baldwin wrote: On 17-Jan-01 Soren Schmidt wrote: Nothing special, GENERIC kernel with SMP defined will do nicely, running without SMP improves matters but on the fastet machine I'm still getting lockups, but they are rare... AHA! Useful info!! GENERIC is quite close to bloated, so the fact that it is GENERIC + SMP maybe an edge case. I'll try and test this out now that you have actually provided some useful info. :-P If you want a stable box, try trimming the kernel config down to what you need. You read too much into that, I dont normally run a GENERIC kernel, I run one stripped down to what I need, I gave you guys a generic example of what fails, and what can easily be reproduced. Anyhow, I have asked before to have you guys supply me with a kernel that has been compiled "the right way" and I'll test it out here just to make sure I dont do anything stupid.. Just a bare bones kernel, fxp ata drivers will do nicely for the serverworks thingy, give me an URL I can get it from or put it on ftp.freebsd.dk/incoming and give my a ping when its there... -Sren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Debugging SMP instability (was Re: HEADS-UP: await/asleep removal imminent)
On Wed, Jan 17, 2001 at 07:42:26PM +0100, Soren Schmidt wrote: Basically if you're expecting me or the SMP team to figure out what's going on without more info, you're pretty much out of luck. See above, not really possible, we have been trying to find some (affordable) HW that could be used to preserve a log over a boot, but so far I havn't been able to find anything that works, and is fast enough to not effect the system too much... I did some research on this and am convinced that at least some video cards would work as memory buffers for KTR logs. Specifically, someone mentioned to me yesterday that their Matrox Millennium II flashes the X desktop during startup from a previous invocation across warm boots. (I pursued some alternatives and found the PCI RAM cards to be prohibitively expensive (more than $700), and sound cards to not have enough RAM except on old SoundBlaster AWE cards.) For someone with device driver experience, I expect it would be a few hours of effort to make it possible to use a second video card (or even the primary one for that matter) as a DMA region in which KTR logs can be saved, so that there is a way to debug even these spontaneous reboots you're having. Maybe I'll eventually get to implementing this myself, but to be honest, I don't have a driving need for it right now, whereas you do. =) You're experiencing a stability problem that none of us (SMPng people) can reproduce. We'd love to fix the problem, but without more information, your reports are only slightly more useful than the typical newbie "it's broken" reports, though certainly more frustrating. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
On 17-Jan-01 Matt Dillon wrote: :* Alfred Perlstein [EMAIL PROTECTED] [010117 09:24] wrote: : : I'm not going to axe it for a few days, this is a really amazing : API that Matt added, the problem is utility and useage over code : complexity. : : It's just a proposal. : :I found several places where it may be useful, but I'm not sure if the :benefits outweigh the gains. :... : :The lock must be unwound becasue we're calling MGETHDR with M_TRYWAIT. :If wae used M_TRY'A'WAIT the code would probably look something like :this: The basic premis of using asleep()/await() is to allow you to propogate a 'blocking condition' back up to a higher level rather then blocking deep in side the kernel. Gotcha. Given that, if we switch to using condition variables for this, why not have the low level code return a pointer to a cv to wait on? This would do the same thing using an existing API (now) and I think would serve the same purposes as your API. Returning NULL for a cv would mean that no sleep was required. -- 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: HEADS-UP: await/asleep removal imminent
On 17-Jan-01 Soren Schmidt wrote: It seems John Baldwin wrote: On 17-Jan-01 Soren Schmidt wrote: Nothing special, GENERIC kernel with SMP defined will do nicely, running without SMP improves matters but on the fastet machine I'm still getting lockups, but they are rare... AHA! Useful info!! GENERIC is quite close to bloated, so the fact that it is GENERIC + SMP maybe an edge case. I'll try and test this out now that you have actually provided some useful info. :-P If you want a stable box, try trimming the kernel config down to what you need. You read too much into that, I dont normally run a GENERIC kernel, I run one stripped down to what I need, I gave you guys a generic example of what fails, and what can easily be reproduced. Anyhow, I have asked before to have you guys supply me with a kernel that has been compiled "the right way" and I'll test it out here just to make sure I dont do anything stupid.. Just a bare bones kernel, fxp ata drivers will do nicely for the serverworks thingy, give me an URL I can get it from or put it on ftp.freebsd.dk/incoming and give my a ping when its there... Ok, will do. I'll even compile it on an SMP box. :-P I'm also adding in several debugging options that hopefully will casue it to have an informative panic rather than a hang or reboot. -Søren -- 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: Debugging SMP instability (was Re: HEADS-UP: await/asleep removal imminent)
It seems Jason Evans wrote: On Wed, Jan 17, 2001 at 07:42:26PM +0100, Soren Schmidt wrote: Basically if you're expecting me or the SMP team to figure out what's going on without more info, you're pretty much out of luck. See above, not really possible, we have been trying to find some (affordable) HW that could be used to preserve a log over a boot, but so far I havn't been able to find anything that works, and is fast enough to not effect the system too much... I did some research on this and am convinced that at least some video cards would work as memory buffers for KTR logs. Specifically, someone mentioned to me yesterday that their Matrox Millennium II flashes the X desktop during startup from a previous invocation across warm boots. (I pursued some alternatives and found the PCI RAM cards to be prohibitively expensive (more than $700), and sound cards to not have enough RAM except on old SoundBlaster AWE cards.) Hmm, I've been toying with this, but the el cheapo videocards I have all lose random amounts of their video RAM over a reset, probably due to the DRAM refresh being absent for too long... For someone with device driver experience, I expect it would be a few hours of effort to make it possible to use a second video card (or even the primary one for that matter) as a DMA region in which KTR logs can be saved, so that there is a way to debug even these spontaneous reboots you're having. Maybe I'll eventually get to implementing this myself, but to be honest, I don't have a driving need for it right now, whereas you do. =) Do you need DMA ?? a simple ptr to the mem should do (and much easier to get to work)... You're experiencing a stability problem that none of us (SMPng people) can reproduce. We'd love to fix the problem, but without more information, your reports are only slightly more useful than the typical newbie "it's broken" reports, though certainly more frustrating. Well, I'm not alone thats for sure, and since this has been so for months I've almost gotten to the impression that something fundamental must be wrong, however until now I've just been told to go away :) I know these problems are a bitch to find, but we need to take this at least semi professionalistic and find out whats wrong, or 5.0 will be a disater when it hits the streets. I dont have the time to play around with SMP for the time being, but I do expect the SMPng group to take these problems seriously instead of the "it works here" attitude thats been hollering down the halls lately.. Again I'll offer to run any and all code or patches to -current you guys can come up with, but I simply dont have the time to sit down and analyze into details what you have been doing... -Sren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
In message [EMAIL PROTECTED], Alfred Perlstein writes: * Poul-Henning Kamp [EMAIL PROTECTED] [010117 10:25] wrote: Perhaps you can explain how you're able to trigger this instability with a test script? Poul-Henning told me he just needed to do a make -j256 world, I did 10 of them without a problem... Then you misunderstood me, I don't have anything in the dept of SMP hw which can trigger it. If you could be more vague it would assist me greatly in figuring out what's broken. /sarcasm I have been as clear as possible at all times, so if anything here has been vague, it gotta be in your end. The only reason why I'm in this fracas is to get people to take the anguished cries of sos seriously so that we don't loose our ATA maintainer... -- 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: HEADS-UP: await/asleep removal imminent
On 17-Jan-01 Soren Schmidt wrote: It seems John Baldwin wrote: On 17-Jan-01 Soren Schmidt wrote: Nothing special, GENERIC kernel with SMP defined will do nicely, running without SMP improves matters but on the fastet machine I'm still getting lockups, but they are rare... AHA! Useful info!! GENERIC is quite close to bloated, so the fact that it is GENERIC + SMP maybe an edge case. I'll try and test this out now that you have actually provided some useful info. :-P If you want a stable box, try trimming the kernel config down to what you need. You read too much into that, I dont normally run a GENERIC kernel, I run one stripped down to what I need, I gave you guys a generic example of what fails, and what can easily be reproduced. Anyhow, I have asked before to have you guys supply me with a kernel that has been compiled "the right way" and I'll test it out here just to make sure I dont do anything stupid.. Just a bare bones kernel, fxp ata drivers will do nicely for the serverworks thingy, give me an URL I can get it from or put it on ftp.freebsd.dk/incoming and give my a ping when its there... http://www.FreeBSD.org/~jhb/kernel.sos It was compiled wtih INCLUDE_CONFIG_FILE, so you can grab the config file from that. -Søren -- 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: HEADS-UP: await/asleep removal imminent
In message [EMAIL PROTECTED], Alfred Perlstein writes: There has to be a way for you guys to get us some reasonable tracebacks or diagnostics instead of just saying "it's broke". Its close to impossible, the two symptoms I see here are either spontanous reboots, or solid hangs where only a reset can get you out, so I cant say much other than "it's broke". You probably have a much better understanding of low level programming than I do, you _should_ be able to figure out what's going on. Excuse me! There is no fucking way you guys can expect anybody else to be able to debug at the rate things are being changed right now. Hmm, with a -current kernel from today 1200 CET i just need to do a make depend on a GENERIC kernel, and wham it locks up. Odd, doesn't hang for me. "Absense of evidence is not evidence of absense". Remember that. I think phk just told me that you need a UP kernel to find this, but he's being pretty vague about it so I don't know. No I told you that I have not been able to reproduce this because my SMP boxes are too slow to matter. Or maybe because they have to few and too ancient disks. Or maybe because I don't have time to really give them a beating these days. I don't know. -- 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: HEADS-UP: await/asleep removal imminent
In message [EMAIL PROTECTED], John Baldwin writes: On 17-Jan-01 Poul-Henning Kamp wrote: Perhaps you can explain how you're able to trigger this instability with a test script? Poul-Henning told me he just needed to do a make -j256 world, I did 10 of them without a problem... Then you misunderstood me, I don't have anything in the dept of SMP hw which can trigger it. Ok, what _does_ trigger this then? My theory is that it's related to disk-IO. My guess is that it may be related to calling a *_strategy() routine from an interrupt routine. That is what sets ccd, ata-raid and vinum apart from normal disk-IO. -- 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: HEADS-UP: await/asleep removal imminent
::... :: ::The lock must be unwound becasue we're calling MGETHDR with M_TRYWAIT. ::If wae used M_TRY'A'WAIT the code would probably look something like ::this: : : The basic premis of using asleep()/await() is to allow you to : propogate a 'blocking condition' back up to a higher level rather : then blocking deep in side the kernel. : :Gotcha. Given that, if we switch to using condition variables for this, why :not have the low level code return a pointer to a cv to wait on? This would do :the same thing using an existing API (now) and I think would serve the same :purposes as your API. Returning NULL for a cv would mean that no sleep was :required. : :-- : :John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ You could but that would require massive changes to the API for many of the calls. It's probably easier for the low level code to passively install the pointer into the proc structure and return 'NULL' - which is more likely to already be supported or mostly supported by the API. Don't get me wrong, the caller needs to know what is going on, but there is something to be said for not passing yet another argument to half the procedures in the kernel :-) One of the best things about a passive pointer in the proc structure as per my proposal is that the caller can decide to ignore it, can NULL it out, can leave it in place and propogate the failure upwards, or can replace it with another condition pointer. This gives the caller an incredible amount of flexibility in how it decides to handle the blocking condition, all without introducing any overhead. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
John, It might be nice with a "How to provide useful info on SMPng problems." FAQ somewhere. I have no idea which of all the WITNESS and other options do what and when they are useful... -- 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: HEADS-UP: await/asleep removal imminent
It seems John Baldwin wrote: Anyhow, I have asked before to have you guys supply me with a kernel that has been compiled "the right way" and I'll test it out here just to make sure I dont do anything stupid.. Just a bare bones kernel, fxp ata drivers will do nicely for the serverworks thingy, give me an URL I can get it from or put it on ftp.freebsd.dk/incoming and give my a ping when its there... http://www.FreeBSD.org/~jhb/kernel.sos It was compiled wtih INCLUDE_CONFIG_FILE, so you can grab the config file from that. Roger, I'll put it on as soon as the box finishes what its doing now, I'll get back to you... -Sren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
On 17-Jan-01 Poul-Henning Kamp wrote: John, It might be nice with a "How to provide useful info on SMPng problems." FAQ somewhere. I have no idea which of all the WITNESS and other options do what and when they are useful... Fair enough. One thing on my todo list is a ktr.9 manpage documenting its use as it is one of the things I've found useful so far. Some other general docco I'll try and come up with as well. -- 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: Atomic breakage?
On 2001-Jan-17 10:43:10 -0500, Garrett Wollman [EMAIL PROTECTED] wrote: On Wed, 17 Jan 2001 14:26:54 +1100, Peter Jeremy [EMAIL PROTECTED] said: To support multiple masters, you need proper locks. On older processors, yes. On processors with the CX8 feature bit set, you can do it without any sort of locking (indeed, this is a primitive that semaphores can be built upon). This particular sub-thread was specifically discussing the 80386 - as I thought was clear from the context. I am aware of the CMPXCHG8B insn, but it's not relevant to the 386 or 486. On pre-Pentium processors (which lack the CX8 feature) this sort of sequence is impossible. OTOH, I don't think SMP works on any pre-Pentium processor, so again this degenerates to: There are SMP machines using both 386 and 486 processors. There is no support in FreeBSD for SMP on pre-Pentium processors. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Atomic breakage?
On Thu, 18 Jan 2001 07:06:09 +1100, Peter Jeremy [EMAIL PROTECTED] said: There are SMP machines using both 386 and 486 processors. There is no support in FreeBSD for SMP on pre-Pentium processors. Yes, I well recall the Sequent. I wish for it to remain a memory. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
Poul-Henning Kamp [EMAIL PROTECTED] writes: It might be nice with a "How to provide useful info on SMPng problems." FAQ somewhere. I'd also like a "KTR for fun and profit" FAQ... I have no idea which of all the WITNESS and other options do what and when they are useful... WITNESS, at least, is fairly well documented in NOTES. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
subscribe woody@woodwrecker.com
subscribe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Zero-copy TCP patches - missing in action?
Weren't the zero-copy patches supposed to make it into -current some time back? I recall a little grumbling over it since it made it necessary for some other projects to sync up their own work, but nobody seemed to object in principal and zero-copy TCP is a real marketing point if we can actually implement and use it constructively. Inquiring minds want to know, etc. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Zero-copy TCP patches - missing in action?
On Wed, Jan 17, 2001 at 12:59:28 -0800, Jordan Hubbard wrote: Weren't the zero-copy patches supposed to make it into -current some time back? I recall a little grumbling over it since it made it necessary for some other projects to sync up their own work, but nobody seemed to object in principal and zero-copy TCP is a real marketing point if we can actually implement and use it constructively. Inquiring minds want to know, etc. Well, there are a few things that came up when I proposed putting it into -current (on the -arch list), and I haven't gotten around to fixing those yet. Part of the problem is that I have changed jobs, and no longer have access to the hardware I was using to test things out with. Drew Gallatin has supplied remotely accessible hardware that I can use to debug things, so the main thing I need at at the moment is time to fix the issues that Bosko, Matt Dillon and others had with the code. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
On 17-Jan-01 Dag-Erling Smorgrav wrote: Poul-Henning Kamp [EMAIL PROTECTED] writes: It might be nice with a "How to provide useful info on SMPng problems." FAQ somewhere. I'd also like a "KTR for fun and profit" FAQ... ktr.9 is next on my todo list of manpages to write. I have several sitting in the queue pending review right now, but that is the next one I can start writing, hopefully sometime this week. Now that my release build box is stable and reliable again, I'm testing out releases with debug options turned on by default in GENERIC. I'm also playing with having a kernel.debug in the kernel snap by default as well. -- 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: number of processes forked since boot
Hajimu UMEMOTO schrieb:
Hi,
I wish to obtain number of processes forked since boot from userland.
So, I made a patch to intend to commit.
Any comment?
I have done a similar approach. I was inspired by the "vmstat -s" output of
Solaris.
Therefor my solution was integrated into the vmmeter structure. Adding sysctl
variables
would be trivial though.
Warning: The diff is from a very old source tree. It may not apply cleanly.
But
the modifications are trivial and should be easily spotted.
--
Daniel
Index: sys/kern/kern_exec.c
===
RCS file: /data/cvs/src/sys/kern/kern_exec.c,v
retrieving revision 1.116
diff -u -r1.116 kern_exec.c
--- sys/kern/kern_exec.c2000/09/21 09:04:17 1.116
+++ sys/kern/kern_exec.c2000/09/21 17:34:09
@@ -47,6 +47,7 @@
#include sys/shm.h
#include sys/sysctl.h
#include sys/vnode.h
+#include sys/vmmeter.h
#include vm/vm.h
#include vm/vm_param.h
@@ -374,7 +375,10 @@
}
if (error == 0)
+ {
+ ++cnt.v_exec;
return (0);
+ }
exec_fail:
if (imgp-vmspace_destroyed) {
Index: sys/kern/kern_fork.c
===
RCS file: /data/cvs/src/sys/kern/kern_fork.c,v
retrieving revision 1.82
diff -u -r1.82 kern_fork.c
--- sys/kern/kern_fork.c2000/09/14 23:07:39 1.82
+++ sys/kern/kern_fork.c2000/09/15 23:07:29
@@ -55,6 +55,7 @@
#include sys/ktr.h
#include sys/ktrace.h
#include sys/unistd.h
+#include sys/vmmeter.h
#include sys/jail.h
#include vm/vm.h
@@ -105,6 +106,7 @@
if (error == 0) {
p-p_retval[0] = p2-p_pid;
p-p_retval[1] = 0;
+ ++cnt.v_fork;
}
return error;
}
@@ -122,6 +124,7 @@
if (error == 0) {
p-p_retval[0] = p2-p_pid;
p-p_retval[1] = 0;
+ ++cnt.v_vfork;
}
return error;
}
Index: sys/sys/vmmeter.h
===
RCS file: /data/cvs/src/sys/sys/vmmeter.h,v
retrieving revision 1.21
diff -u -r1.21 vmmeter.h
--- sys/sys/vmmeter.h 1999/12/29 04:24:49 1.21
+++ sys/sys/vmmeter.h 1999/12/31 02:41:29
@@ -92,6 +92,9 @@
u_int v_pageout_free_min; /* min number pages reserved for kernel */
u_int v_interrupt_free_min; /* reserved number of pages for int code */
u_int v_free_severe;/* severe depletion of pages below this pt */
+ u_int v_fork;
+ u_int v_vfork;
+ u_int v_exec;
};
#ifdef _KERNEL
Index: usr.bin/vmstat/vmstat.c
===
RCS file: /data/cvs/src/usr.bin/vmstat/vmstat.c,v
retrieving revision 1.39
diff -u -r1.39 vmstat.c
--- usr.bin/vmstat/vmstat.c 2000/05/05 16:07:10 1.39
+++ usr.bin/vmstat/vmstat.c 2000/05/07 21:11:18
@@ -599,6 +599,12 @@
(void)printf("%9u cpu context switches\n", sum.v_swtch);
(void)printf("%9u device interrupts\n", sum.v_intr);
(void)printf("%9u software interrupts\n", sum.v_soft);
+ (void)printf("%9u forks\n", sum.v_fork);
+ (void)printf("%9u vforks\n", sum.v_vfork);
+ (void)printf("%9u execs\n", sum.v_exec);
+#ifdef vax
+ (void)printf("%9u pseudo-dma dz interrupts\n", sum.v_pdma);
+#endif
(void)printf("%9u traps\n", sum.v_trap);
(void)printf("%9u system calls\n", sum.v_syscall);
(void)printf("%9u swap pager pageins\n", sum.v_swapin);
@@ -731,7 +737,7 @@
errx(1, "malloc");
kread(X_INTRCNT, intrcnt, (size_t)nintr);
kread(X_INTRNAMES, intrname, (size_t)inamlen);
- (void)printf("interrupt total rate\n");
+ (void)printf("interrupttotal rate\n");
inttotal = 0;
nintr /= sizeof(long);
while (--nintr = 0) {
Re: HEADS-UP: await/asleep removal imminent
* Bosko Milekic [EMAIL PROTECTED] [010117 14:35] wrote: Alfred Perlstein wrote: Which means we don't have to drop the lock over the socket unless we'd block on allocation. No. You'd still have to drop it for now. Remember? (Last commit to uipc_mbuf.c). You have to drop it because of the problem you may have if Giant is gotten before your sockbuf/socket lock. In the allocation, you may be acquiring Giant again. I don't know the exact semantics, but if you at some point may grab the sockbuf/socket lock without already holding Giant and call the allocation routine, you're opening the door for deadlock. The rest of the patches unwind giant on entry into the socket layer so grabbing Giant shouldn't be a problem. Matt, is this what you intended for it to do? So far I've only seen it used to avoid races, but not to optimize out mutex aquire/release. I've only seen it to be useful to avoid races. If you're holding a lock and you need to sleep but if you drop the lock before you actually switch you may get woken up and never find out, thus still going to sleep. With the asleep you could hold the lock and place yourself on the sleep queue such that when you drop the lock and call await, you'll find out if you've gotten awoken (you'll be removed from the sleep queue). With the interlocking with sched_lock now down in msleep(), this "feature" of asleep/await is useless. Read the rest of my posts, the ones not cc'd to everyone, just Matt and -arch. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: I386_CPU
On Tuesday, 16 January 2001 at 9:28:43 -0500, Will Andrews wrote: On Tue, Jan 16, 2001 at 09:16:14AM -0500, Kenneth Wayne Culver wrote: Wont this make installing using sysinstall a bit hard? I know the generic kernel includes all the CPU lines, so that all cpu's are recognized... so are you going to just take this line out of the generic kernel, and have a special kern.flp disk with a generic kernel that only has the i386 support in it? I don't think it's worth the effort. By the time 5.0-RELEASE goes out, the 386 will have been around for over 10 years (actually I think it has already reached that point and gone beyond). There are not likely to be many more installs of FreeBSD on 386's, let alone 5.x installs. People who *really* want to install 5.x on a 386 can generate their own kernel and such. Don't forget that the i386 is still a popular CPU for embedded work. Of course, embedded people will have less of an issue with sysinstall. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: I386_CPU
On Wed, Jan 17, 2001 at 04:21:15PM +1100, Greg Lehey wrote: Don't forget that the i386 is still a popular CPU for embedded work. Of course, embedded people will have less of an issue with sysinstall. Of course. But of these people, which really need 5.x's features over 4.x? Plus they can still compile I386_CPU by itself, which I'm sure they already do to keep the kernel size as small as possible. -- wca PGP signature
Re: Debugging SMP instability (was Re: HEADS-UP: await/asleep removal imminent)
:I did some research on this and am convinced that at least some video cards :would work as memory buffers for KTR logs. Specifically, someone mentioned :to me yesterday that their Matrox Millennium II flashes the X desktop :during startup from a previous invocation across warm boots. (I pursued :some alternatives and found the PCI RAM cards to be prohibitively expensive :(more than $700), and sound cards to not have enough RAM except on old :SoundBlaster AWE cards.) My Voodoo 3 2000 does the same thing... crash, reboot, bring up X, and the original pre-boot display flashes before X reinitializes the screen. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: I386_CPU
On Wednesday, 17 January 2001 at 19:16:18 -0500, Will Andrews wrote: On Wed, Jan 17, 2001 at 04:21:15PM +1100, Greg Lehey wrote: Don't forget that the i386 is still a popular CPU for embedded work. Of course, embedded people will have less of an issue with sysinstall. Of course. But of these people, which really need 5.x's features over 4.x? I thought about that, too. I came to the conclusion "probably not", but 4.x won't be maintained for ever. Plus they can still compile I386_CPU by itself, which I'm sure they already do to keep the kernel size as small as possible. Sure. As I said, the installation would be much more specific anyway. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
On Wed, 17 Jan 2001, Alfred Perlstein wrote: I have a patch here that removes await/asleep from the kernel API. http://people.freebsd.org/~alfred/noasleep.diff Matt Dillon implemented alseep/await quite some time ago and the only thing that's using it is ata. In order to clean up some of the schduler and vm system I'm removing support for it. Hmm, I've found this API usable for synchronization between two kernel threads/processes: alseep(somewhere); wakeup(anotherprocess); await(somewhere); where 'anotherprocess' do some job and call wakeup(somewhere). I suspect that this can be emulated with mutexes and/or conditional variables. So, it is possible to keep the API, but change its implementation to allow mentioned cleanup of scheduler ? P.S. it is already too hard to maintain external kernel modules even within various releng_4s, not to mention -current and releng_3... -- 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: Debugging SMP instability (was Re: HEADS-UP: await/asleep removal imminent)
Again I'll offer to run any and all code or patches to -current you
guys can come up with, but I simply dont have the time to sit down
and analyze into details what you have been doing...
The enclosed patch implements a virtual NMI pushbutton by programming
the IOAPIC to deliver an NMI when sio1 generates an interrupt.
DDB should be defined in the kernel config file.
getty should not run on ttyd1 when this patch is applied.
A serial console on sio0 is recommended.
If you still cannot break into the kernel debugger when the machine
locks up then a rogue device is probably blocking the system
(or the debugger is trying to obtain a mutex held by somebody else)
- Tor Egge
Index: sys/i386/i386/mpapic.c
===
RCS file: /home/ncvs/src/sys/i386/i386/mpapic.c,v
retrieving revision 1.45
diff -u -r1.45 mpapic.c
--- sys/i386/i386/mpapic.c 2001/01/10 04:43:46 1.45
+++ sys/i386/i386/mpapic.c 2001/01/18 05:44:30
@@ -269,6 +269,41 @@
/* return GOOD status */
return 0;
}
+
+
+void
+enable_sio_NMI(int irq)
+{
+ u_char select; /* the select register is 8 bits */
+ u_int32_t flags; /* the window register is 32 bits */
+ u_int32_t target;/* the window register is 32 bits */
+ u_int32_t vector;/* the window register is 32 bits */
+ int apic;
+ int pin;
+
+ if (irq 0 || irq 15) {
+ printf("Could not enable NMI for irq %d\n", irq);
+ return;
+ }
+ apic = int_to_apicintpin[irq].ioapic;
+ pin = int_to_apicintpin[irq].int_pin;
+
+ target = CPU_TO_ID(0) 24;
+ select = IOAPIC_REDTBL0 + (2 * pin);
+ vector = TPR_FAST_INTS + irq;
+ flags = ((u_int32_t)
+ (IOART_INTMCLR |
+ IOART_TRGREDG |
+ IOART_INTAHI |
+ IOART_DESTPHY |
+ IOART_DELNMI));
+
+ io_apic_write(apic, select, flags | vector);
+ io_apic_write(apic, select + 1, target);
+ printf("Enabled NMI for irq %d\n", irq);
+ printf("XXX IOAPIC #%d intpin %d -irq %d vector 0x%x (Delivery mode NMI)\n",
+ apic, pin, irq, vector);
+}
#undef DEFAULT_ISA_FLAGS
#undef DEFAULT_FLAGS
Index: sys/i386/i386/trap.c
===
RCS file: /home/ncvs/src/sys/i386/i386/trap.c,v
retrieving revision 1.164
diff -u -r1.164 trap.c
--- sys/i386/i386/trap.c2001/01/10 04:43:46 1.164
+++ sys/i386/i386/trap.c2001/01/18 05:44:30
@@ -248,7 +248,8 @@
atomic_add_int(cnt.v_trap, 1);
- if ((frame.tf_eflags PSL_I) == 0) {
+ if ((frame.tf_eflags PSL_I) == 0
+ frame.tf_trapno != T_NMI) {
/*
* Buggy application or kernel code has disabled
* interrupts and then trapped. Enabling interrupts
@@ -285,8 +286,38 @@
enable_intr();
}
- mtx_enter(Giant, MTX_DEF);
+ if (frame.tf_trapno == T_NMI) {
+ /* If we can't get Giant then forward NMI to next CPU */
+ if (mtx_try_enter(Giant, MTX_DEF) == 0) {
+ u_long icr_lo;
+ u_long icr_hi;
+ int target;
+
+ target = PCPU_GET(cpuid) + 1;
+ if (((1 target) PCPU_GET(other_cpus)) == 0)
+ target = 0;
+
+ /* write the destination field for the target AP */
+ icr_hi = (lapic.icr_hi ~APIC_ID_MASK) |
+ (cpu_num_to_apic_id[target] 24);
+ lapic.icr_hi = icr_hi;
+
+ /* write command */
+ icr_lo = (lapic.icr_lo APIC_RESV2_MASK) |
+ APIC_DEST_DESTFLD | APIC_DELMODE_NMI | 0xff;
+ lapic.icr_lo = icr_lo;
+
+ /* wait for pending status end */
+ while (lapic.icr_lo APIC_DELSTAT_MASK)
+ /* spin */ ;
+ __asm __volatile("int $0xff");
+
+ return;
+ }
+ } else
+ mtx_enter(Giant, MTX_DEF);
+
#if defined(I586_CPU) !defined(NO_F00F_HACK)
restart:
#endif
@@ -388,6 +419,9 @@
*/
if (ddb_on_nmi) {
printf ("NMI ... going to debugger\n");
+ sioEATintr();
+ __asm __volatile("int $0xff");
+ enable_intr();
kdb_trap (type, 0, frame);
}
#endif /* DDB
Re: HEADS UP: I386_CPU
In message [EMAIL PROTECTED] Greg Lehey writes: : Don't forget that the i386 is still a popular CPU for embedded work. : Of course, embedded people will have less of an issue with sysinstall. We have basically an embedded environment and we don't use sysinstall at all for building our CF. And we're targeting 486 and 586 class processors that have enough juice to run sysinstall. It is easier to create the part and put it into the device than it is to create it in-suitu. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: I386_CPU
In message [EMAIL PROTECTED] Will Andrews writes: : Of course. But of these people, which really need 5.x's features over : 4.x? Plus they can still compile I386_CPU by itself, which I'm sure : they already do to keep the kernel size as small as possible. That's a red herring. The new features thing is what I mean. If I were creating a product, I'd want one that is supported. So even if I don't *NEED* a feature in 5.x, I might migrate my product to 5.x so that I can continue to get bug fixes and leverage more support than I can get with an older rev. One of the 5.x features might well be a new compiler. I don't see that sort of thing being back ported to 4.x at this point. That's one of the big reasons that we're 4.x based right now rather than 3.x based, despite 4.x's slightly larger memory footprint. That and 4.x's much better c++ compiler. So it isn't as simple as you are trying to paint it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: I386_CPU
In message [EMAIL PROTECTED] Greg Lehey writes: : Of course. But of these people, which really need 5.x's features over : 4.x? : : I thought about that, too. I came to the conclusion "probably not", : but 4.x won't be maintained for ever. Compiler technology maybe? But maintainence and "mind share" with the main FreeBSD developer team are also issues that someone in this situation will need to consider. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
It seems John Baldwin wrote: Anyhow, I have asked before to have you guys supply me with a kernel that has been compiled "the right way" and I'll test it out here just to make sure I dont do anything stupid.. Just a bare bones kernel, fxp ata drivers will do nicely for the serverworks thingy, give me an URL I can get it from or put it on ftp.freebsd.dk/incoming and give my a ping when its there... http://www.FreeBSD.org/~jhb/kernel.sos It was compiled wtih INCLUDE_CONFIG_FILE, so you can grab the config file from that. Now this is "interesting", I booted on your kernel, and it has run through make world 4 times in a row... So I felt lucky, checked out a new fresh src/sys tree, and made a new kernel from the config file you used, reboot, starts test, and *HANG* Hmm!! Now I have tried a sys tree from today (0800 CET) two days ago and a week ago, and all 3 of them produces the lockup. So the only thing I can think of is that you guys have something in your src trees that cvs I dont... Now what ? -Sren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
* Soren Schmidt [EMAIL PROTECTED] [010118 00:03] wrote: It seems John Baldwin wrote: Anyhow, I have asked before to have you guys supply me with a kernel that has been compiled "the right way" and I'll test it out here just to make sure I dont do anything stupid.. Just a bare bones kernel, fxp ata drivers will do nicely for the serverworks thingy, give me an URL I can get it from or put it on ftp.freebsd.dk/incoming and give my a ping when its there... http://www.FreeBSD.org/~jhb/kernel.sos It was compiled wtih INCLUDE_CONFIG_FILE, so you can grab the config file from that. Now this is "interesting", I booted on your kernel, and it has run through make world 4 times in a row... So I felt lucky, checked out a new fresh src/sys tree, and made a new kernel from the config file you used, reboot, starts test, and *HANG* Hmm!! Now I have tried a sys tree from today (0800 CET) two days ago and a week ago, and all 3 of them produces the lockup. So the only thing I can think of is that you guys have something in your src trees that cvs I dont... Now what ? What are the compile flags you are using? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
