Re: make buildkernel hang with SCHED_ULE
Dr. Richard E. Hawkins said: On Thu, Aug 14, 2003 at 10:49:42PM -0400, Adam Migus wrote: Andrew Gallatin wrote: WRT the mime thing. My apologies. It never occured to me as everyone I know personally uses a real mail reader. I'd attached them simply to keep the scrolling down and allow order independant viewing. Thanks for the tip. I'll just read them in as plain text in the future. If it gives mail or mh problems, it doesn't work on *real* mail readers. :) hawk, ignobly usin mutt -- Richard E. Hawkins, Asst. Prof. of Economics/\ ASCII ribbon campaign [EMAIL PROTECTED] Smeal 178 (814) 375-4700 \ / against HTML mail These opinions will not be those of Xand postings. Penn State until it pays my retainer. / \ Well, I guess we're back to that whole, what is real thing. So if for the sake of argument, if works with mime were the qualification for a real mail reader and everyone stopped using mime, would all mail readers become not real? Gee, that could be problematic. There must be something else that makes a mail reader real. Otherwise we'd better hope people keep using mime. If continued, I think this belongs on -chat. :-) -- Adam - Migus Dot Org (http://www.migus.org) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildkernel hang with SCHED_ULE
On Thu, Aug 14, 2003 at 08:17:33PM -0400, Andrew Gallatin wrote: You have machdep.hlt_logical_cpus: 1 in your sysctl output. [BTW, lots of people read this mail via the web archives at http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1073654+0+current/freebsd-current, where its impossible to view mime; it would be MUCH better for us if appended things like stack traces and sysctl output rather then scrambling them for no reason] You can also read the archives at: http://lists.freebsd.org/pipermail/freebsd-current That archive supports MIME. -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildkernel hang with SCHED_ULE
Craig Rodrigues writes: On Thu, Aug 14, 2003 at 08:17:33PM -0400, Andrew Gallatin wrote: You have machdep.hlt_logical_cpus: 1 in your sysctl output. [BTW, lots of people read this mail via the web archives at http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1073654+0+current/freebsd-current, where its impossible to view mime; it would be MUCH better for us if appended things like stack traces and sysctl output rather then scrambling them for no reason] You can also read the archives at: http://lists.freebsd.org/pipermail/freebsd-current That archive supports MIME. But it doesn't have a link to the raw email message so that I can download it via fetch, point my mailer at it and reply.. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildkernel hang with SCHED_ULE
On Thu, Aug 14, 2003 at 10:49:42PM -0400, Adam Migus wrote: Andrew Gallatin wrote: WRT the mime thing. My apologies. It never occured to me as everyone I know personally uses a real mail reader. I'd attached them simply to keep the scrolling down and allow order independant viewing. Thanks for the tip. I'll just read them in as plain text in the future. If it gives mail or mh problems, it doesn't work on *real* mail readers. :) hawk, ignobly usin mutt -- Richard E. Hawkins, Asst. Prof. of Economics/\ ASCII ribbon campaign [EMAIL PROTECTED] Smeal 178 (814) 375-4700 \ / against HTML mail These opinions will not be those of Xand postings. Penn State until it pays my retainer. / \ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildkernel hang with SCHED_ULE
Adam Migus writes: Folks, While doing some performance analysis (doing make -j5 buildkernel) on a set of 14 kernels I've hit one using the SCHED_ULE scheduler that hangs. It happens every time but not necessarily in the same place in the make. ... The hardware is a dual Xeon box. The kernel is SMP w/ SCHED_ULE instead of SCHED_4BSD, the options required for diskless and the following two options: You have machdep.hlt_logical_cpus: 1 in your sysctl output. [BTW, lots of people read this mail via the web archives at http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1073654+0+current/freebsd-current, where its impossible to view mime; it would be MUCH better for us if appended things like stack traces and sysctl output rather then scrambling them for no reason] SCHED_ULE is incompatible with halting logical CPUs. Something about it does't know the core isn't running, so it schedules a job there which never runs, and then it gets confused. When I boot a 1 CPU P4 with an SMP kernel and machdep.hlt_logical_cpus=1, it hangs before making it to multiuser mode.. Try setting machdep.hlt_logical_cpus=0 (via sysctl now, and in /boot/loader.conf so it doesn't happen again). Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildkernel hang with SCHED_ULE
Andrew Gallatin wrote: Adam Migus writes: Folks, While doing some performance analysis (doing make -j5 buildkernel) on a set of 14 kernels I've hit one using the SCHED_ULE scheduler that hangs. It happens every time but not necessarily in the same place in the make. ... The hardware is a dual Xeon box. The kernel is SMP w/ SCHED_ULE instead of SCHED_4BSD, the options required for diskless and the following two options: You have machdep.hlt_logical_cpus: 1 in your sysctl output. [BTW, lots of people read this mail via the web archives at http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1073654+0+current/freebsd-current, where its impossible to view mime; it would be MUCH better for us if appended things like stack traces and sysctl output rather then scrambling them for no reason] SCHED_ULE is incompatible with halting logical CPUs. Something about it does't know the core isn't running, so it schedules a job there which never runs, and then it gets confused. When I boot a 1 CPU P4 with an SMP kernel and machdep.hlt_logical_cpus=1, it hangs before making it to multiuser mode.. Try setting machdep.hlt_logical_cpus=0 (via sysctl now, and in /boot/loader.conf so it doesn't happen again). Drew Andrew, WRT the mime thing. My apologies. It never occured to me as everyone I know personally uses a real mail reader. I'd attached them simply to keep the scrolling down and allow order independant viewing. Thanks for the tip. I'll just read them in as plain text in the future. WRT the sysctl value. Thanks for the tip. Is this to be considered a bug in SCHED_ULE? If the default is hlt_logical_cpus=1 I would think the scheduler should be able to handle it or deal with it appropriately. Perhaps ignoring the value, setting it to 0 internally or even just putting a warning message on boot? After all, not everyone RTFM's. :-) Thanks again, -- Adam - Migus Dot Org (http://www.migus.org) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildkernel hang with SCHED_ULE
On Thu, 14 Aug 2003, Adam Migus wrote: Andrew Gallatin wrote: Adam Migus writes: Folks, While doing some performance analysis (doing make -j5 buildkernel) on a set of 14 kernels I've hit one using the SCHED_ULE scheduler that hangs. It happens every time but not necessarily in the same place in the make. ... The hardware is a dual Xeon box. The kernel is SMP w/ SCHED_ULE instead of SCHED_4BSD, the options required for diskless and the following two options: You have machdep.hlt_logical_cpus: 1 in your sysctl output. [BTW, lots of people read this mail via the web archives at http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1073654+0+current/freebsd-current, where its impossible to view mime; it would be MUCH better for us if appended things like stack traces and sysctl output rather then scrambling them for no reason] SCHED_ULE is incompatible with halting logical CPUs. Something about it does't know the core isn't running, so it schedules a job there which never runs, and then it gets confused. When I boot a 1 CPU P4 with an SMP kernel and machdep.hlt_logical_cpus=1, it hangs before making it to multiuser mode.. Try setting machdep.hlt_logical_cpus=0 (via sysctl now, and in /boot/loader.conf so it doesn't happen again). Drew Andrew, WRT the mime thing. My apologies. It never occured to me as everyone I know personally uses a real mail reader. I'd attached them simply to keep the scrolling down and allow order independant viewing. Thanks for the tip. I'll just read them in as plain text in the future. WRT the sysctl value. Thanks for the tip. Is this to be considered a bug in SCHED_ULE? If the default is hlt_logical_cpus=1 I would think the scheduler should be able to handle it or deal with it appropriately. Perhaps ignoring the value, setting it to 0 internally or even just putting a warning message on boot? After all, not everyone RTFM's. :-) The MD code does not currently export the status of the CPUs in any reliable way. ULE attempts to recognize halted CPUs but it is not able to due to other issues. I think john baldwin might be solving this for x86. If not I can take a stab at it again. Thanks again, -- Adam - Migus Dot Org (http://www.migus.org) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildkernel hang with SCHED_ULE
On Mon, Aug 11, 2003 at 11:09:44PM -0400, Adam Migus wrote: The hardware is a dual Xeon box. The kernel is SMP w/ SCHED_ULE instead of SCHED_4BSD, the options required for diskless and the following two options: options CPU_FASTER_5X86_FPU options CPU_UPGRADE_HW_CACHE Why are you using these options? they shouldn't be required for a Xeon. Are you able to break in to DDB to run a ps to inspect the process table via the debugger key or NMI? BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildkernel hang with SCHED_ULE
Bruce M Simpson said: On Mon, Aug 11, 2003 at 11:09:44PM -0400, Adam Migus wrote: The hardware is a dual Xeon box. The kernel is SMP w/ SCHED_ULE instead of SCHED_4BSD, the options required for diskless and the following two options: options CPU_FASTER_5X86_FPU options CPU_UPGRADE_HW_CACHE Why are you using these options? they shouldn't be required for a Xeon. Are you able to break in to DDB to run a ps to inspect the process table via the debugger key or NMI? BMS Bruce, I also do testing on a dual Althon and honestly didn't bother to research whether they'd have any affect. Could/would they be causing a problem? I'll recompile without them and try again at any rate. As of now I haven't tried anything. I'd image I can break to DDB as the machine is responsive when it happens. Can you give me any helpful hints on what to look for and/or how to diagnose? -- Adam - Migus Dot Org (http://www.migus.org) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildkernel hang with SCHED_ULE
On Thu, Aug 14, 2003 at 05:45:28PM -0400, Adam Migus wrote: I also do testing on a dual Althon and honestly didn't bother to research whether they'd have any affect. Could/would they be causing a problem? I'll recompile without them and try again at any rate. They are old options for enabling hardware cache on machines which have had a processor upgrade installed, or for enabling Cyrix 5x86 FPU handler options. They are documented in NOTES. I could find scant documentation on the FASTFPE bit. http://www.sandpile.org/ia32/ccr.htm#ccr4 suggests that it was only ever used on the old 486 pin-compatible Cyrix 5x86. It is possible setting these bits has an undefined effect on your more recent machines. Try compiling a kernel without them and see if your scheduler problem manifests itself. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
