Re: KSE M-III status junior hacker project.
On Mon, Jul 08, 2002 at 07:28:50PM -0400, Anthony Jenkins wrote: I finally shelled out Radio Shack's ridiculous amount for a null modem cable and can do remote debugging now, but I can't remember the URL for that recent series of articles on getting started with CURRENT debugging...anyone? TIA, Anthony Joe I think you're looking for these: http://www.onlamp.com/pub/a/bsd/2002/03/21/Big_Scary_Daemons.html http://www.onlamp.com/pub/a/bsd/2002/04/04/Big_Scary_Daemons.html - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: 0DB5 8563 2473 C72A A8D1 56EA DAD2 B05D 5F3C 3185 GPG Key ID : DAD2B05D5F3C3185 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: KSE M-III status junior hacker project.
On 06-Jul-2002 Julian Elischer wrote: Well with various hints from here and there I have fixed the ^Z/fg problem (at least it seems fixed to me and others that have tested) This basically leaves only one outstanding problem that I know of which is a problem that Warner has with a particular progam. (This may also be fixed but I don't know) If anyone knows of something that was broken by the KSE commit, (i.e. it worked just before and not after) and is STILL broken please let me know because I think I can pretty much declare that chapter finished, and I'd like to get on with extending KSE functionality. This will be the start of Milestone IV, which would be add support for threads to run on multiple processors. Coincident with that some work should also proceed on gradually identifying and cleaning up places in the kernel where multithreading is just not ready.. e.g. which thread status do you get when you type ^T? I would like it if you would make KSE-3 work on other architectures now rather than adding more functionality that only works on i386. This would serve to validate the design decisions made thus far before a whole lot of code depends on those design decisions making it easier to make changes if need be. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE M-III status junior hacker project.
On Monday 2002-July-08 19:47, Don Lewis wrote: On 8 Jul, Anthony Jenkins wrote: I've been looking at the pcm code and I can see where it locks, then allocates memory with the M_WAITOK flag thing. I'm wondering if there's a standard procedure for fixing these... would I just nail down the malloc to a non-sleepable one? Only if the the code can cope with malloc() failing and returning NULL if the memory isn't immediately available. In most cases a better solution is to allocate the memory before grabbing the lock. Thanks... I'll take a look at this tonight after work. -- Anthony Jenkins To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: KSE M-III status junior hacker project.
On Tue, 9 Jul 2002, John Baldwin wrote: If anyone knows of something that was broken by the KSE commit, (i.e. it worked just before and not after) and is STILL broken please let me know because I think I can pretty much declare that chapter finished, and I'd like to get on with extending KSE functionality. This will be the start of Milestone IV, which would be add support for threads to run on multiple processors. Coincident with that some work should also proceed on gradually identifying and cleaning up places in the kernel where multithreading is just not ready.. e.g. which thread status do you get when you type ^T? I would like it if you would make KSE-3 work on other architectures now rather than adding more functionality that only works on i386. This would serve to validate the design decisions made thus far before a whole lot of code depends on those design decisions making it easier to make changes if need be. I have to admit I got a bit nervous about the KSE work on learning that the existing fork-like approach was not compatible with several of our new (or existing) target architectures; my impression was Julian and Doug had hashed out a good solution to the problem at the dev summit last month, however. I agree that getting at least one non-i386 platform working at this point is really an important priority, since we really don't want to bump into any more such problems. Also, since we're now getting to the point where userland work is feasible, I think it's important that we start to congeal a bit more on the multi-platform aware interface to avoid building in assumptions that will be broken later resulting in a lot more work. Julian--following your conversation/design session with Doug, how long do you think it would take to get i386 moved over to the revised design, and then assuming you and someone infinitely familiar with the target platform sat down together, how long would it take to bootstrap at least one more platform to work with KSE? I tend to agree with John that this is an important thing to have happen before we get too much more featureful. To make an additional platform happen (say, Alpha or Sparc64), what would it take in terms of expertise you don't have -- just someone familiar with the architecture's context management and kernel trap code? I.e., a day or two of Doug's, Jake's, or Peter's time? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: KSE M-III status junior hacker project.
On Tue, 9 Jul 2002, Robert Watson wrote: On Tue, 9 Jul 2002, John Baldwin wrote: If anyone knows of something that was broken by the KSE commit, (i.e. it worked just before and not after) and is STILL broken please let me know because I think I can pretty much declare that chapter finished, and I'd like to get on with extending KSE functionality. This will be the start of Milestone IV, which would be add support for threads to run on multiple processors. Coincident with that some work should also proceed on gradually identifying and cleaning up places in the kernel where multithreading is just not ready.. e.g. which thread status do you get when you type ^T? I would like it if you would make KSE-3 work on other architectures now rather than adding more functionality that only works on i386. This would serve to validate the design decisions made thus far before a whole lot of code depends on those design decisions making it easier to make changes if need be. I have to admit I got a bit nervous about the KSE work on learning that the existing fork-like approach was not compatible with several of our new (or existing) target architectures; my impression was Julian and Doug had hashed out a good solution to the problem at the dev summit last month, however. I agree that getting at least one non-i386 platform working at this point is really an important priority, since we really don't want to bump into any more such problems. Also, since we're now getting to the point where userland work is feasible, I think it's important that we start to congeal a bit more on the multi-platform aware interface to avoid building in assumptions that will be broken later resulting in a lot more work. The reason that I couldn't commit it immediatly was that I had to rewrite some small parts to fit the new design that came from those discussions. As for userland.. that's basically a question for Dan. Chris Provenso who wrote the original MIT threads package indicated an interest in also taking part. Julian--following your conversation/design session with Doug, how long do you think it would take to get i386 moved over to the revised design, and then assuming you and someone infinitely familiar with the target platform sat down together, how long would it take to bootstrap at least one more platform to work with KSE? I tend to agree with John that this is an important thing to have happen before we get too much more featureful. To make an additional platform happen (say, Alpha or Sparc64), what would it take in terms of expertise you don't have -- just someone familiar with the architecture's context management and kernel trap code? I.e., a day or two of Doug's, Jake's, or Peter's time? I386 is already running on the revised design. (though there is some cleanup that could be done) To get this running on another architecture, it takes the MD parts of the 386 KSE code being rewritten to fit the other architectures. I think it would take a couple of hours for someone infinitely familiar with the target to write those parts.. there are a couple hundred lines of C at most that need to be written. Basically the MD code requires that someone writes three major functions: 1/ write a thread's state to a given location in user memory so that it can be restarted. 2/ create a new thread context ready for an upcall, so that the upcall will jump to a given function with a given argument on a given stack. 3/ In user land, a pair of functions (setcontext and getcontext) to save and load a thread userland context in a compatible form with that saved in (1). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE M-III status junior hacker project.
On Sun, Jul 07, 2002 at 12:34:06PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Josef Karthauser [EMAIL PROTECTED] writes: : I've absolutely no idea what's causing it, but I'm still having random reboots : of current after some uptime with no dumps. I'll install a new kernel : today and report back if it still happens. Maybe someone can help me to : track it down. I had similar problems when Julian first committed KSE III, but I've not had them since updating to more recent, and stable, kernels. Now I get random panics with core dumps :-) On a new kernel I appear to be getting dumps now (along with the crashes ;). Actually it's pretty stable, but there are random crashes occuring, usually I come back to the machine when I've not used it for a new hours and find it in rebooted and in the kernel debugging due to those pcm may sleep locked type things. Joe -- As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. - Albert Einstein, 1921 msg40663/pgp0.pgp Description: PGP signature
Re: KSE M-III status junior hacker project.
On Monday 2002-July-08 14:08, Josef Karthauser wrote: On a new kernel I appear to be getting dumps now (along with the crashes ;). Actually it's pretty stable, but there are random crashes occuring, usually I come back to the machine when I've not used it for a new hours and find it in rebooted and in the kernel debugging due to those pcm may sleep locked type things. I've been looking at the pcm code and I can see where it locks, then allocates memory with the M_WAITOK flag thing. I'm wondering if there's a standard procedure for fixing these... would I just nail down the malloc to a non-sleepable one? Also the lock could be freed before it's unlocked... is this okay? I'm guessing it is... mtx_assert(mtx, MA_OWNED); mtx_destroy(mtx); Every time I load my sound driver, top(1) shows the irq10 entry to be locked in *Giant state, and if I unload it and do a kldstat it's instant panic. I finally shelled out Radio Shack's ridiculous amount for a null modem cable and can do remote debugging now, but I can't remember the URL for that recent series of articles on getting started with CURRENT debugging...anyone? TIA, Anthony Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE M-III status junior hacker project.
On 8 Jul, Anthony Jenkins wrote: I've been looking at the pcm code and I can see where it locks, then allocates memory with the M_WAITOK flag thing. I'm wondering if there's a standard procedure for fixing these... would I just nail down the malloc to a non-sleepable one? Only if the the code can cope with malloc() failing and returning NULL if the memory isn't immediately available. In most cases a better solution is to allocate the memory before grabbing the lock. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE M-III status junior hacker project.
On Sun, 7 Jul 2002, Josef Karthauser wrote: On Sat, Jul 06, 2002 at 04:57:08PM -0700, Julian Elischer wrote: Well with various hints from here and there I have fixed the ^Z/fg problem (at least it seems fixed to me and others that have tested) This basically leaves only one outstanding problem that I know of which is a problem that Warner has with a particular progam. (This may also be fixed but I don't know) If anyone knows of something that was broken by the KSE commit, (i.e. it worked just before and not after) and is STILL broken please let me know because I think I can pretty much declare that chapter finished, and I'd like to get on with extending KSE functionality. This will be the start of Milestone IV, which would be add support for threads to run on multiple processors. Coincident with that some work should also proceed on gradually identifying and cleaning up places in the kernel where multithreading is just not ready.. e.g. which thread status do you get when you type ^T? I've absolutely no idea what's causing it, but I'm still having random reboots of current after some uptime with no dumps. I'll install a new kernel today and report back if it still happens. Maybe someone can help me to track it down. I'm having problems like that every 1-3 days, but my build is pre-KSE-III (post-gcc-3.1 though). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
5.0 DP2 (was Re: KSE M-III status junior hacker project.)
On Sat, Jul 06, 2002 at 04:57:08PM -0700, Julian Elischer wrote: Well with various hints from here and there I have fixed the ^Z/fg problem (at least it seems fixed to me and others that have tested) This basically leaves only one outstanding problem that I know of which is a problem that Warner has with a particular progam. (This may also be fixed but I don't know) Hi Julian, Thanks for your progress on KSE! How long should we wait before branching in Perforce for 5.0 DP2? I would like to give at least 10 more days for this and other changes to settle before making the branch. If all goes well, I would like to release 5.0 DP2 at the end of this month. - Murray To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE M-III status junior hacker project.
On Sat, Jul 06, 2002 at 04:57:08PM -0700, Julian Elischer wrote: Well with various hints from here and there I have fixed the ^Z/fg problem (at least it seems fixed to me and others that have tested) This basically leaves only one outstanding problem that I know of which is a problem that Warner has with a particular progam. (This may also be fixed but I don't know) If anyone knows of something that was broken by the KSE commit, (i.e. it worked just before and not after) and is STILL broken please let me know because I think I can pretty much declare that chapter finished, and I'd like to get on with extending KSE functionality. This will be the start of Milestone IV, which would be add support for threads to run on multiple processors. Coincident with that some work should also proceed on gradually identifying and cleaning up places in the kernel where multithreading is just not ready.. e.g. which thread status do you get when you type ^T? I've absolutely no idea what's causing it, but I'm still having random reboots of current after some uptime with no dumps. I'll install a new kernel today and report back if it still happens. Maybe someone can help me to track it down. Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE M-III status junior hacker project.
In message: [EMAIL PROTECTED] Josef Karthauser [EMAIL PROTECTED] writes: : I've absolutely no idea what's causing it, but I'm still having random reboots : of current after some uptime with no dumps. I'll install a new kernel : today and report back if it still happens. Maybe someone can help me to : track it down. I had similar problems when Julian first committed KSE III, but I've not had them since updating to more recent, and stable, kernels. Now I get random panics with core dumps :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE M-III status junior hacker project.
On 2002-07-07 11:46 +, Josef Karthauser wrote: I've absolutely no idea what's causing it, but I'm still having random reboots of current after some uptime with no dumps. I'll install a new kernel today and report back if it still happens. Maybe someone can help me to track it down. Same happens to me, in addition the file systems aren't unmounted cleanly even if I manually shut down the machine. I built world with sources from around 11:30PM EST yesterday, and so far I've had only one random reboot (so I guess it's 'partly fixed'), as opposed to one every hour on average. I only caught something useful on one of the reboots as I was hanging around the console for a while: panic: lockmgr: draining against myself syncing disks... panic: bwrite: buffer is not busy ??? This was before my latest world/kernel. I'm about to build world again in the hope that something has fixed it. I'm assuming that my initial worries that KSE was causing this may be wrong and it's the vfs changes that have been going in lately (correct me if I'm way off here). -- Munish Chopra The FreeBSD NVIDIA Driver Initiative http://nvidia.netexplorer.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0 DP2 (was Re: KSE M-III status junior hacker project.)
hopefully some of the new work that will be done on kse can be done
on the mainline now without breaking nonKSE activities..
in other words, most of the real it breaks current behaviour
changes have been passed for a while so new code can be off in
if (KSE_mode) { }
clauses that will have no effect on normal usage.
I think that as far as KSE is concerned, you could branch pretty much any
time now..
If there turn out to be problems that we fix they can always be merged
over later.
On Sun, 7 Jul 2002, Murray Stokely wrote:
On Sat, Jul 06, 2002 at 04:57:08PM -0700, Julian Elischer wrote:
Well with various hints from here and there I have fixed
the ^Z/fg problem (at least it seems fixed to me and others that
have tested) This basically leaves only one outstanding
problem that I know of which is a problem that Warner has with a
particular progam. (This may also be fixed but I don't know)
Hi Julian,
Thanks for your progress on KSE! How long should we wait before
branching in Perforce for 5.0 DP2? I would like to give at least 10
more days for this and other changes to settle before making the
branch. If all goes well, I would like to release 5.0 DP2 at the end
of this month.
- Murray
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
KSE M-III status junior hacker project.
Well with various hints from here and there I have fixed the ^Z/fg problem (at least it seems fixed to me and others that have tested) This basically leaves only one outstanding problem that I know of which is a problem that Warner has with a particular progam. (This may also be fixed but I don't know) If anyone knows of something that was broken by the KSE commit, (i.e. it worked just before and not after) and is STILL broken please let me know because I think I can pretty much declare that chapter finished, and I'd like to get on with extending KSE functionality. This will be the start of Milestone IV, which would be add support for threads to run on multiple processors. Coincident with that some work should also proceed on gradually identifying and cleaning up places in the kernel where multithreading is just not ready.. e.g. which thread status do you get when you type ^T? -- On that topic I'd like to suggest a junior hacker project for a couple of hackers that would like to sink their teeth into something but are feeling intimidated. The project would be design some options as to what 'ps' and 'top' should show for multithreaded processes, and then work up a set of patches that would allow them to do it.. This would include extending the kernel interface used by ps to handle multiple threads, using hte current interface as a guide, and altering the programs themselves. Anyone interested in this should contect me.. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
