Re: I can't believe this!
Look guys, it only takes a few keystrokes to fix/remove/reassign incorrectly quoted material. I *obviously* did not make that utterly idiotic statement, PLEASE STOP QUOTING IT AS COMING FROM ME! Sheesh. If I ever find the bozo he is going to quite seriously wind up with a few metric tons of shit in his front yard. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: I can't believe this!
* De: Matthew Dillon [EMAIL PROTECTED] [ Data: 2002-08-21 ] [ Subjecte: Re: I can't believe this! ] Look guys, it only takes a few keystrokes to fix/remove/reassign incorrectly quoted material. I *obviously* did not make that utterly idiotic statement, PLEASE STOP QUOTING IT AS COMING FROM ME! Sheesh. If They could be the other Matt Dillon - the actor. Let's all boycott his films! -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: starting a program on a given ttyv
On Wed, 21 Aug 2002, bruno schwander wrote: any suggestions ? watch or a shared screen could do it...both a bit dodgy though. Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: I can't believe this!
On Thu, 22 Aug 2002, Juli Mallett wrote: They could be the other Matt Dillon - the actor. Let's all boycott his films! i'm amazed you don't already. ---/ f. johan beisser /--+ http://caustic.org/~jan [EMAIL PROTECTED] John Ashcroft is really just the reanimated corpse of J. Edgar Hoover. -- Tim Triche To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Memory corruption in CURRENT
Hi all,
I suspect all the SIG4 and SIG11 problems we see are due
memory corruption in CURRENT.
In the latter case, the affected file looks like:
case HASH('^', 'e'):
case HASH('^', 'i'):
case HASH('^' 'o'):
\xc0 case HASH('^', 'u'):
%case HADH('`', \xc0A'):
^@ase HASH('`', 'E'):
case HASH('`', 'I'):
case HASH('`', 'O'):
case HASH('`', 'U'):
The file is correct after a reboot, so the corruption was limited to the
copy cached in RAM.
Thats memory corruption. I'm also not able anymore
to make 10 buildworlds (without -j, that triggers
panics in pmap code).
Bye the way, I'm experiencing this since about 4-5 months.
All hackers, please help to track this down.
Martin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: starting a program on a given ttyv
bruno schwander wrote: How can I remotely start a program on the console ? I need to remotely launch a fullscreen graphical program, without being logged at the physical console, and redirect the input of the program so I can feed it data (keystrokes) through the network. any suggestions ? The answer depends on the program, and what's already running. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Creating a sysctl? (mission impossible)
Thus spake Mario Sergio Fujikawa Ferreira [EMAIL PROTECTED]: I am trying to create one sysctl so that I can read information from a lottery scheduler that I am trying to write. The sysctl is very very simple. I add a lottery node under kern then add a member global_tickets under kern.lottery. Very simple stuff that is not working. FYI, lottery scheduling has already been implemented at least twice for FreeBSD. For an example, see http://www.csua.berkeley.edu/computing/software/lottery-sched.html The code has not been maintained, FYI, I wanted to have a look, but it appears that both a link to source code http://www-2.cs.cmu.edu/~dpetrou/code/freebsd_lottery_code.tar.gz and to accompanying paper http://www-2.cs.cmu.edu/~dpetrou/papers/freebsd_lottery_writeup98.ps do not work ... apparently due to a lack of interest, and it incurs a high scheduling overhead. Note that the KSE work is likely to bring significant changes to scheduling in FreeBSD, possibly causing you headaches later. You might also be interested in Luigi's work on a PS scheduler; check the list archives. Regards, Andrei To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
On Thu, Aug 22, 2002 at 09:43:45AM +0200, Martin Blapp wrote:
I suspect all the SIG4 and SIG11 problems we see are due
memory corruption in CURRENT.
In the latter case, the affected file looks like:
case HASH('^', 'e'):
case HASH('^', 'i'):
case HASH('^' 'o'):
\xc0 case HASH('^', 'u'):
%case HADH('`', \xc0A'):
^@ase HASH('`', 'E'):
case HASH('`', 'I'):
case HASH('`', 'O'):
case HASH('`', 'U'):
The file is correct after a reboot, so the corruption was limited to the
copy cached in RAM.
Thats memory corruption. I'm also not able anymore
to make 10 buildworlds (without -j, that triggers
panics in pmap code).
Bye the way, I'm experiencing this since about 4-5 months.
All hackers, please help to track this down.
Is it P4 specific or not?
Mark
--
Mark Santcroos RIPE Network Coordination Centre
http://www.ripe.net/home/mark/ New Projects Group/TTM
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
It seems Martin Blapp wrote: Hi all, I suspect all the SIG4 and SIG11 problems we see are due memory corruption in CURRENT. The file is correct after a reboot, so the corruption was limited to the copy cached in RAM. Thats memory corruption. I'm also not able anymore to make 10 buildworlds (without -j, that triggers panics in pmap code). Bye the way, I'm experiencing this since about 4-5 months. All hackers, please help to track this down. Hmm, I haven't seen this at all, but I've just started buildworld loops on two machines here, but I normally do at least a couble buildworlds a day and I havn't notice problems like the above (but plenty of bad commits etc). However, this kind of problem in most cases spells bad HW to me, ie subspec RAM, poor powersupply, badly cooled CPU, overclocking etc etc... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
Hi Soeren, However, this kind of problem in most cases spells bad HW to me, ie subspec RAM, poor powersupply, badly cooled CPU, overclocking etc etc... That's what I thought too. I have now three different systems which show all this: 1) PIV 1,6Ghz, Intel B845DG Board, 1GB Kingston Ram, 2) PIV 2Ghz Intel B845DG Board, 1GB Kingston ECC Ram 3) PIV 2,26 Ghz Asus P4B533 Board with I845 chipset, 1GB noname Ram All running CURRENT. I also replaced in 1) and 2) the CPU, RAM. It happens both on SCSI and ATA disks. Powersupply has been changed for all 3 systems. Problem is still the same. The problem sometimes appears just after startup. CPU is still cold then. Other times it builds 6 buildworlds sucessfully, and then suddenly I see a SIG4. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
It seems Martin Blapp wrote: Hi Soeren, However, this kind of problem in most cases spells bad HW to me, ie subspec RAM, poor powersupply, badly cooled CPU, overclocking etc etc... That's what I thought too. I have now three different systems which show all this: 1) PIV 1,6Ghz, Intel B845DG Board, 1GB Kingston Ram, 2) PIV 2Ghz Intel B845DG Board, 1GB Kingston ECC Ram 3) PIV 2,26 Ghz Asus P4B533 Board with I845 chipset, 1GB noname Ram All running CURRENT. I also replaced in 1) and 2) the CPU, RAM. It happens both on SCSI and ATA disks. Powersupply has been changed for all 3 systems. Problem is still the same. The problem sometimes appears just after startup. CPU is still cold then. Other times it builds 6 buildworlds sucessfully, and then suddenly I see a SIG4. Hmm, thats probably a P4 problem then, I dont see it on any of my systems (P3 + K7) I dont have a P4 here (and newer will unless left at my doorstep), and I have no immediate ideas other than trying a MB that doesn't have a i845 chipset (the less Intel parts the better :) ) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
On Thu, Aug 22, 2002 at 11:23:46 +0200, Martin Blapp wrote: That's what I thought too. I have now three different systems which show all this: 1) PIV 1,6Ghz, Intel B845DG Board, 1GB Kingston Ram, 2) PIV 2Ghz Intel B845DG Board, 1GB Kingston ECC Ram 3) PIV 2,26 Ghz Asus P4B533 Board with I845 chipset, 1GB noname Ram All running CURRENT. I also replaced in 1) and 2) the CPU, RAM. It happens both on SCSI and ATA disks. Powersupply has been changed for all 3 systems. Problem is still the same. The problem sometimes appears just after startup. CPU is still cold then. Other times it builds 6 buildworlds sucessfully, and then suddenly I see a SIG4. Only a little addition from me: I had the same problems on -stable and they only disappeared after compiling the kernel without debugging. I had the impression that it has to do with the size of the kernel (but this of course maybe wrong). After dropping -g from kernel compiling I hadn't a problem again on -stable. (At the moment I do not have -current on a P-IV, the motherboard is a Fujitsu-Siemens) Best regards -- Udo Schweigert, Siemens AG | Voice : +49 89 636 42170 CT IC CERT, Siemens CERT | Fax: +49 89 636 41166 D-81730 Muenchen / Germany | email : [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
On 22 Aug, Mark Santcroos wrote: On Thu, Aug 22, 2002 at 09:43:45AM +0200, Martin Blapp wrote: Thats memory corruption. I'm also not able anymore to make 10 buildworlds (without -j, that triggers panics in pmap code). Bye the way, I'm experiencing this since about 4-5 months. All hackers, please help to track this down. Is it P4 specific or not? Nope. I'm seeing it on an AMD Athlon XP 1900+. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
Soeren Schmidt wrote: It seems Martin Blapp wrote: I suspect all the SIG4 and SIG11 problems we see are due memory corruption in CURRENT. The file is correct after a reboot, so the corruption was limited to the copy cached in RAM. Thats memory corruption. I'm also not able anymore to make 10 buildworlds (without -j, that triggers panics in pmap code). Bye the way, I'm experiencing this since about 4-5 months. All hackers, please help to track this down. Hmm, I haven't seen this at all, but I've just started buildworld loops on two machines here, but I normally do at least a couble buildworlds a day and I havn't notice problems like the above (but plenty of bad commits etc). However, this kind of problem in most cases spells bad HW to me, ie subspec RAM, poor powersupply, badly cooled CPU, overclocking etc etc... Try: options DISABLE_PSE options DISABLE_PG_G -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
On Thu, Aug 22, 2002 at 11:30:50AM +0200, Udo Schweigert wrote: Only a little addition from me: I had the same problems on -stable and they only disappeared after compiling the kernel without debugging. I had the impression that it has to do with the size of the kernel (but this of course maybe wrong). After dropping -g from kernel compiling I hadn't a problem again on -stable. (At the moment I do not have -current on a P-IV, the motherboard is a Fujitsu-Siemens) I will try that asap. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
Martin Blapp wrote: I have now three different systems which show all this: 1) PIV 1,6Ghz, Intel B845DG Board, 1GB Kingston Ram, 2) PIV 2Ghz Intel B845DG Board, 1GB Kingston ECC Ram 3) PIV 2,26 Ghz Asus P4B533 Board with I845 chipset, 1GB noname Ram All running CURRENT. I also replaced in 1) and 2) the CPU, RAM. It happens both on SCSI and ATA disks. Powersupply has been changed for all 3 systems. Problem is still the same. The problem sometimes appears just after startup. CPU is still cold then. Other times it builds 6 buildworlds sucessfully, and then suddenly I see a SIG4. Alternatively, rather than those options, try losing 512M of the RAM... I note they are all 1G boxes. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
Hi Martin, As you know this problem for longer, did you already try to make the problem a bit more reproducable / narrowed down? If not, we really should try to, that will be the first step in fixing it. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
On Thu, Aug 22, 2002 at 02:38:25AM -0700, Terry Lambert wrote: Alternatively, rather than those options, try losing 512M of the RAM... I note they are all 1G boxes. No, mine is 256MB. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
On 22 Aug, Soeren Schmidt wrote: However, this kind of problem in most cases spells bad HW to me, ie subspec RAM, poor powersupply, badly cooled CPU, overclocking etc etc... My motherboard chipset supports ECC RAM and I have ECC RAM installed. I upgraded to an expensive Antec power supply that has better specs than most of the other supplies I looked at. The system is plugged into a surge supressor. I don't currently have an UPS. I added an extra case fan and drive cooler fans, and the two failures happened in the evening after the room cooled off. For some reason xmbmon doesn't seem to be working at the moment, but when I looked at the temperatures previously they seemed to be acceptable. I don't believe in overclocking. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
Mark Santcroos wrote: On Thu, Aug 22, 2002 at 02:38:25AM -0700, Terry Lambert wrote: Alternatively, rather than those options, try losing 512M of the RAM... I note they are all 1G boxes. No, mine is 256MB. Correction: all of his were 1G, and should be halved. *You*, on the other hand, should try doubling the RAM size. 8-). Another potential winner is: options maxfiles=5 Note that I believe this one, the RAM size change, and the compile without debug all merely mask, rather than fixing, the problem (i.e. it's not the code that's generated, it's a side effect of a more subtle and amusing problem). I don't believe anyone actually loads kernels with debug symbols anyway if you config -g GENERIC, unless you intentionally copy up kernel.debug, you will get the stripped one). The suggested options, if they work, actually *fix* the problem, but it's a really pessimal way to go about it (they work by making the requisite preconditions impossible to trigger); only an idiot would run with those options, unless they had no other choice in the matter (e.g. they had local kernel hacks that broke all of the other workarounds, with no hope of repair). If it's what I think it is, it's more fixable than that. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
On Thu, Aug 22, 2002 at 02:33:57AM -0700, Terry Lambert wrote: options DISABLE_PSE options DISABLE_PG_G Coming up next in this theater :-) btw, how does the report that using the other compiler fixed everything for KT fit in? -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Creating a sysctl? (mission impossible)
Thus spake Andrei A. Dergatchev [EMAIL PROTECTED]: FYI, lottery scheduling has already been implemented at least twice for FreeBSD. For an example, see http://www.csua.berkeley.edu/computing/software/lottery-sched.html The code has not been maintained, FYI, I wanted to have a look, but it appears that both a link to source code http://www-2.cs.cmu.edu/~dpetrou/code/freebsd_lottery_code.tar.gz and to accompanying paper http://www-2.cs.cmu.edu/~dpetrou/papers/freebsd_lottery_writeup98.ps do not work ... You can download a cached copy of the paper from the following address: http://citeseer.nj.nec.com/112654.html The first half of the paper mentions some interesting implementation details that Waldspurger didn't; the second half contains a bunch of benchmarks that are not particularly well analyzed. It looks like the code is available from the author's website, with a 2.5-yr-old port to 4-STABLE. http://www-2.cs.cmu.edu/~dpetrou/research.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Creating a sysctl? (mission impossible)
with a 2.5-yr-old port to 4-STABLE. http://www-2.cs.cmu.edu/~dpetrou/research.html Btw, we still use it quite successfully with minor modifications on mass hosting backend servers. Currently, with 4.6-STABLE. It really makes a difference. -- Andrey Alekseyev. Zenon N.S.P. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
Hi This is what I did the to system's cc/gcc. I built gcc3.1.1 released version from the ports (with much pain of coz). passion:/usr/bin[514]# ls -l cc* gcc* lrwxr-xr-x 1 root wheel 20 Aug 12 21:54 cc - /usr/local/bin/gcc31 -r-xr-xr-x 2 root wheel 135616 Aug 12 21:52 cc.sav lrwxr-xr-x 1 root wheel 20 Aug 12 21:54 gcc - /usr/local/bin/gcc31 -r-xr-xr-x 2 root wheel 135616 Aug 12 21:52 gcc.sav The hardware = Asus P4S533 + P4 1.6A (now 2.4Ghz) + Kingston DDR333 value ram. Haven't encountered any random signal or stability issue since I swapped cc/gcc with ports' version. Will try to run 10 buildworlds in a row later tonight. kt On Thu, Aug 22, 2002 at 12:00:14PM +0200, Mark Santcroos wrote: On Thu, Aug 22, 2002 at 02:33:57AM -0700, Terry Lambert wrote: options DISABLE_PSE options DISABLE_PG_G Coming up next in this theater :-) btw, how does the report that using the other compiler fixed everything for KT fit in? -- Mark SantcroosRIPE Network Coordination Centre http://www.ripe.net/home/mark/New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
Mark Santcroos wrote: On Thu, Aug 22, 2002 at 02:33:57AM -0700, Terry Lambert wrote: options DISABLE_PSE options DISABLE_PG_G Coming up next in this theater :-) btw, how does the report that using the other compiler fixed everything for KT fit in? Coincidentally. It's hard to trigger the bug, so it's easy to work around it accidently. Most people who run into these type of bugs only really care about getting things working, so if they accidently work around the thing, they stop there, without digging down to discover the root cause. It's much better to find out the root cause than to submerge the bug again; making it go away for unknown reasons means it will probably come back for unknown reasons at a later point, and bite you on the butt. No one in their right mind could believe that recompining a user space application to avoid kernel-based faults actually fixes the underlying problem. If I had to voice a theory, I would say that the change in memory access patterns resulted in the problem being submerged again. Most likely, a different set of system load characteristics could cause it to resurface, everything else being the same (in fact, that's what I would say is happening with the original compiler; workarounds are commutative). It's not really predictable at what future point that could/would happen, so you basically you end up being left with a live landmine somewhere in your back yard, and you think it's safe because poodles no longer explode 15 minutes after they are tied to the apple tree. 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
On 22 Aug, Terry Lambert wrote: Alternatively, rather than those options, try losing 512M of the RAM... I note they are all 1G boxes. When I first put this system together several months ago, I only installed the first 512M of RAM and the problem was much worse. I only had about a 50% chance of getting a successful buildworld. The problem seemed to go away shortly thereafter, and though I wasn't sure whether the problem was caused by hardware or software, I attributed the improvement to an upgrade to a newer version of -current. Since then I've replaced the motherboard (the old one didn't support ECC), the disk and controller (I needed more space, and the new disk consumes a lot less power than the two that it replaced, plus it doesn't sound like a dental drill), and the power supply (because I was concerned that the original might be marginal). I also added an extra intake fan on the front of the case. At the moment I'm running a set of buildworlds with an August 6th kernel, just to verify the problem that I'm seeing isn't something new. When I'm done with that, I'll reduce the RAM from 1G to 512M and try again. I'll also try the DISABLE_PSE and DISABLE_PG_G options. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
On Thu, Aug 22, 2002 at 03:17:03AM -0700, Terry Lambert wrote: Mark Santcroos wrote: On Thu, Aug 22, 2002 at 02:33:57AM -0700, Terry Lambert wrote: options DISABLE_PSE options DISABLE_PG_G Coming up next in this theater :-) btw, how does the report that using the other compiler fixed everything for KT fit in? It looks indeed like it is a 'winner'. The buildworld is still running but getting further already than the previous 10. Coincidentally. It's hard to trigger the bug, so it's easy to work around it accidently. Thats very true indeed. I can take that as a good 'explanation'. I remember you talking about this PSE problems earlier and more often. Is it fixable? I assume we would like to turn these options back on as they improve performance don't they? Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
Hi, options DISABLE_PSE options DISABLE_PG_G Just added them. I'll now build 20 buildworlds with those enabled. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
Don Lewis wrote: At the moment I'm running a set of buildworlds with an August 6th kernel, just to verify the problem that I'm seeing isn't something new. When I'm done with that, I'll reduce the RAM from 1G to 512M and try again. I'll also try the DISABLE_PSE and DISABLE_PG_G options. Please do these seperately. Changing the amount of RAM is only indicative, not diagnostic, so it's just additional information, if it does anything, instead of nothing. With Matt Dillon's changes to machdep.c to do auto-tuning, changing the amount of RAM is much less likely to work around the problem, unless you hit the stair function at just the right point. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
Mark Santcroos wrote: On Thu, Aug 22, 2002 at 03:17:03AM -0700, Terry Lambert wrote: Mark Santcroos wrote: On Thu, Aug 22, 2002 at 02:33:57AM -0700, Terry Lambert wrote: options DISABLE_PSE options DISABLE_PG_G Coming up next in this theater :-) btw, how does the report that using the other compiler fixed everything for KT fit in? It looks indeed like it is a 'winner'. The buildworld is still running but getting further already than the previous 10. Ugh! Wait until it seems to work for a statistically significant sample size, and for more than one person before calling it happy! Also, I'm not sure looking at the code whether or not the PG_G is truly significant, or just preterbs the workaround. The problem I've referred to in my hunch here is actually related solely to the PSE, but with the recent code reorganization in locore.s, etc., it could have become more significant. Coincidentally. It's hard to trigger the bug, so it's easy to work around it accidently. Thats very true indeed. I can take that as a good 'explanation'. I remember you talking about this PSE problems earlier and more often. Is it fixable? I assume we would like to turn these options back on as they improve performance don't they? Yes and yes, but it could be pretty ugly. It would be better to get more data from people who are seeing the problem. It may be that it's just similar symptoms and more than one proot cause, etc., so I'm pretty loathe to make any assumptions. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
Martin Blapp wrote: options DISABLE_PSE options DISABLE_PG_G Just added them. I'll now build 20 buildworlds with those enabled. Let the list know if it does anything. If Soren could also test, that would give a sample size. If it's a 3-for-3 workaround, then I probably need to take the discussion offline with Peter Wemm, and come up with a permanent fix. If it's not 3-for-3, then more testing and thinking is needed. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
On Thu, Aug 22, 2002 at 04:23:46AM -0700, Terry Lambert wrote: Ugh! Wait until it seems to work for a statistically significant sample size, and for more than one person before calling it happy! Also, I'm not sure looking at the code whether or not the PG_G is truly significant, or just preterbs the workaround. The problem I've referred to in my hunch here is actually related solely to the PSE, but with the recent code reorganization in locore.s, etc., it could have become more significant. I was just giving a slight report, not yelling halleluja yet ;-) It's doing the 2nd buildworld now. Do you also want me to try to split up the disabling of the two options? Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
On Thu, Aug 22, 2002 at 04:31:02AM -0700, Terry Lambert wrote: If it's a 3-for-3 workaround, then I probably need to take the discussion offline with Peter Wemm, and come up with a permanent fix. There was something with non-disclosure, am I right? -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
It seems Terry Lambert wrote: Martin Blapp wrote: options DISABLE_PSE options DISABLE_PG_G Just added them. I'll now build 20 buildworlds with those enabled. Let the list know if it does anything. If Soren could also test, that would give a sample size. Sure, but I dont have the problem :) I can buildworld for days on my (heavily overclocked btw) Athlon with no problems at all... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
Hi, Can you revert back to the system compiler and also compile your kernel with this options and do some buildworlds again? Thanks Mark On Thu, Aug 22, 2002 at 01:41:13PM +0200, Soeren Schmidt wrote: It seems Terry Lambert wrote: Martin Blapp wrote: options DISABLE_PSE options DISABLE_PG_G Just added them. I'll now build 20 buildworlds with those enabled. Let the list know if it does anything. If Soren could also test, that would give a sample size. Sure, but I dont have the problem :) I can buildworld for days on my (heavily overclocked btw) Athlon with no problems at all... -S?ren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
It seems Mark Santcroos wrote: Hi, Can you revert back to the system compiler and also compile your kernel with this options and do some buildworlds again? I already use the system compiler... On Thu, Aug 22, 2002 at 01:41:13PM +0200, Soeren Schmidt wrote: Sure, but I dont have the problem :) I can buildworld for days on my (heavily overclocked btw) Athlon with no problems at all... -S?ren -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
On Thu, Aug 22, 2002 at 01:55:42PM +0200, Soeren Schmidt wrote: Can you revert back to the system compiler and also compile your kernel with this options and do some buildworlds again? I already use the system compiler... That's why the message was addressed to kt ;-) -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
Mark Santcroos wrote: On Thu, Aug 22, 2002 at 04:31:02AM -0700, Terry Lambert wrote: If it's a 3-for-3 workaround, then I probably need to take the discussion offline with Peter Wemm, and come up with a permanent fix. There was something with non-disclosure, am I right? No. If it's even the same problem, I figured out what was going on by myself, not for an employer, by being obsessive about details, and spending well over a week on my need to know why?. I had *seen* the problem at two previous employers, but neither of them were interested in me wasting time on the why?, once there was a workaround available. No reason to give the information away to competitors, if there's nothing in it but that they become more competitive... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
Mark Santcroos wrote: On Thu, Aug 22, 2002 at 01:41:13PM +0200, Soeren Schmidt wrote: Sure, but I dont have the problem :) I can buildworld for days on my (heavily overclocked btw) Athlon with no problems at all... Can you revert back to the system compiler and also compile your kernel with this options and do some buildworlds again? You are making the same mistake I did. We should be asking Udo Schweigert and KT Sin. Soeren doesn't have any P4's or AMD's with the problem. Hmmm... P4... AMD... have to wonder if someone looked at someone else's paper during the test... ;^). Here's the list of people I have, from a casual look at the archives for this week: Mark Santcroos Martin Blapp (P4) Udo Schweigert (P4, new compiler workaround) KT Sin (P4, new compiler workaround) Don Lewis (AMD Athlon) Alexander Leidinger (P4) David O'Brien (AMD) Alfred Perlstein (?) If we could get most or all of them to try the workaround, it would provide useful information... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
On Thu, Aug 22, 2002 at 05:21:54AM -0700, Terry Lambert wrote: Mark Santcroos wrote: On Thu, Aug 22, 2002 at 01:41:13PM +0200, Soeren Schmidt wrote: Sure, but I dont have the problem :) I can buildworld for days on my (heavily overclocked btw) Athlon with no problems at all... Can you revert back to the system compiler and also compile your kernel with this options and do some buildworlds again? You are making the same mistake I did. No, you are making the same mistake as Soren ;-) I did ask KT, look at the 'To:' field. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Query shared libraries
Is there a way to specify a function in a shared library as the main entry point for my C++ application instead of usual main function? -Vinoth To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Creating a sysctl? (mission impossible)
On Wed, Aug 21, 2002 at 08:08:20PM -0700, David Schultz wrote: Thus spake Mario Sergio Fujikawa Ferreira [EMAIL PROTECTED]: I am trying to create one sysctl so that I can read information from a lottery scheduler that I am trying to write. The sysctl is very very simple. I add a lottery node under kern then add a member global_tickets under kern.lottery. Very simple stuff that is not working. FYI, lottery scheduling has already been implemented at least twice for FreeBSD. For an example, see I know about the other implementations. However, this is for my graduation course. Therefore, I will be implementing it. It would much better if it was suitable for proper inclusion in the kernel. Besides, since this is for my graduation course, I have avoiding checking similar implementations to avoid design plagiarization. Nevertheless, I might check similar implementations to get some ideas now that I'm reaching the higher level abstractions. [snip] The code has not been maintained, apparently due to a lack of interest, and it incurs a high scheduling overhead. Note that the KSE Well, the high overhead has usually been due to the design implementation. It is usually due to the data structure used for holding the processes in the scheduler. Aside from that, the only really expensive call is random(). I am trying to use least expensive design in this code but I am aware of this possible caveat. work is likely to bring significant changes to scheduling in FreeBSD, possibly causing you headaches later. You might also be interested in I know. :) But since I need this working in the next week, I can't really risk trying -CURRENT. I'll have to port this to -CURRENT later since I want all of Waldspurger's proportional schedulers eventually merged into the FreeBSD distribution. Of course, if I can convince -arch ppl that this worth it. Also, users that desire lottery scheduler desire it most for the different policy not exactly for less overhead though I'll try to keep the overhead to a minimum. Luigi's work on a PS scheduler; check the list archives. I will but my current priority is getting lottery scheduler to a working least expensive shape. I think I am going to contact Luigi, he probably has experience with some of the problems I am facing. ps: by the way, for those tracking this from archives. The solution for the sysctl problem is o Problem: Although, the sysctl symbols could be found in the kernel through 'nm /kernel', 'sysctl -a' did not show them. o Solution: Add header file sys/kernel.h which requires sys/param.h o Reason: SYSCTL_* uses the DATA_SET macro, which is in linker_set.h, which is included by kernel.h. If you didn't have it, DATA_SET was giving weird declaration warnings, but i guess since there was nothing in the file it didn't matter when linked [1] Submitted by: ah-zeep [1] So a correct example for adding any sysctl has the following template: #include sys/param.h #include sys/kernel.h #include sys/sysctl.h SYSCTL_NODE(_kern, OID_AUTO, lottery, CTLFLAG_RD, 0, Lottery scheduling parameters); SYSCTL_UINT(_kern_lottery, OID_AUTO, global_tickets, CTLFLAG_RD, global_tickets, 0, Current global tickets); -- Mario S F Ferreira - DF - Brazil - I guess this is a signature. Computer Science Undergraduate | FreeBSD Committer | CS Developer flames to beloved [EMAIL PROTECTED] feature, n: a documented bug | bug, n: an undocumented feature To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Creating a sysctl? (mission impossible)
Thus spake Mario Sergio Fujikawa Ferreira [EMAIL PROTECTED]: Well, the high overhead has usually been due to the design implementation. It is usually due to the data structure used for holding the processes in the scheduler. Aside from that, the only really expensive call is random(). I am trying to use least expensive design in this code but I am aware of this possible caveat. Waldspurger presents one possible PRNG for this purpose in his paper. Nevertheless, I think much of the overhead is inherent in precise lottery scheduling, since you have to consider all runnable processes in the odds at each context switch. Stride scheduling is much nicer in this regard, in addition to offering dependable response times. Berkeley's undergrad OS course actually has students implement a simplification of lottery scheduling as a component of the class project. It's an off-the-wall idea because they don't teach anything about PS schedulers in general, nor do they properly cover the relative merits of lottery scheduling. Fortunately, the task is trivial because the implementation is for a toy OS and efficiency is a non-issue. Best of luck on your project. I'm interested in seeing how your scheduler works out in a real operating system. (I was actually surprised to learn that someone had ported David Petrou's lottery scheduler from FreeBSD 2.2.) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
Mark Santcroos wrote: I was just giving a slight report, not yelling halleluja yet ;-) It's doing the 2nd buildworld now. Do you also want me to try to split up the disabling of the two options? No. Me saying to use both options was just me being lazy about spending 2 days re-documenting the code from boot2 through mi_startup(), to be sure nothing had crept in there. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
We have seen weird problems regarding the pmap PG_G related stuff (well sort of, it has to do with PSE and PG_G) on ppro and pII chips (apparently, this is not the case with at least Xeons) but what happened, for the record, was this: We would enable PSE and switch the pde corresponding to the first 4M to the new entry describing a 4M page, instead of the one describing the location of the ptes covering those 4M. Then, what we would do is walk all the ptes, including those old stale and useless ones that previously described those first 4M and set the PG_G bit there (Note: we've already set PG_G on our 4M page). Normally, we don't really need to touch the old ptes but we did it just because it was more convenient (i.e. a few lines less code). Oddly enough, on the ppro and pII what would happen is that we would page fault on that page where we kept the old ptes covering those first 4M, and only on that page! The other ptes - the ones that actually mattered - were all fine. The ptes are mapped above the 4M so I don't see how changing the pde for those first 4M would have done anything. To fix the problem, we (actually Peter) committed code that basically just jumps beyond that first page of stale ptes when setting the PG_G bit for the 4K pages, and since then, the problem seems to have gone away. Although we are not sure, this seems like a silicon bug. Since then, Peter had some work planned to load the kernel above the first 4M to see if that fixed the problems. I'm wondering if this problem on the PIVs could be related. Please let us know if the removal of those two options really makes 5-10 buildworlds in a row work out for you. Regards, Bosko On Thu, Aug 22, 2002 at 01:34:11PM +0200, Mark Santcroos wrote: On Thu, Aug 22, 2002 at 04:23:46AM -0700, Terry Lambert wrote: Ugh! Wait until it seems to work for a statistically significant sample size, and for more than one person before calling it happy! Also, I'm not sure looking at the code whether or not the PG_G is truly significant, or just preterbs the workaround. The problem I've referred to in my hunch here is actually related solely to the PSE, but with the recent code reorganization in locore.s, etc., it could have become more significant. I was just giving a slight report, not yelling halleluja yet ;-) It's doing the 2nd buildworld now. Do you also want me to try to split up the disabling of the two options? Mark -- Mark SantcroosRIPE Network Coordination Centre http://www.ripe.net/home/mark/New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory corruption in CURRENT
Hi Terry, options DISABLE_PSE options DISABLE_PG_G I'm now at buildworld IV, since I have these options compiled it the bug did not show up again. Another sideeffect: Before that I could not even make -j 10 buildworld, that ended with a page fault somewhere im pmap... This has gone away too. But let's see. I'll build 20 worlds at one row. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
