On 2006/06/12 08:24, Jirtme Loyet wrote: > > Hey, if this problem turns out to expose a true logic bug in > > OpenBSD, go ahead, find it, show us, and get credit for the > > fix. But if "everytime the panic is different", it sounds > > like things are Just Plain Broke on the system, if a BIOS > > upgrade fixes it, sounds like the hardware wasn't set up > > properly, and the manufacturer figured that out, and FIXED > > THE PROBLEM. > > But how to explain that ONLY OpenBSD and NetBSD are buggy. Thousand of > machines are working fine with FreeBSD, many linux and even windows. Every > machine is used in a different manner (streaming server, web server, mail > server, cluster, and so on ...) which make me thought that's it's a net/open > BSD problem. I'm maybe wrong ... But I don't understand why now ;)
...and from earlier: On 2006/06/03 16:11, Jerome Loyet wrote: > > On 2006/06/03 13:46, Jerome Loyet wrote: > > > > > After investigation, the ONLY difference is the version of the > > > > > BIOS. And the difference is: > > > > > The Pstate has been disabled on buggy BIOS and vcore as been > > > > > augmented by 0.1v > > > > One might ask why these things were done. There must be a > > reason because disabling power-saving features and increasing > > core voltage will increase power consumption, so it will cost > > dedibox money to make these changes. > > > > Perhaps they are trying to fix some stability problem... > > The Pstate has been disabled because Pstate is not well supported by > linux kernel < 2.6.15 > The vcore has been increased to speed up the CPU. and from netbsd-tech-kernel: http://marc.theaimsgroup.com/?l=netbsd-tech-kern&m=114935452005690&w=2 > I've recompile the -stable GENERIC kernel without the ENHANCED_SPEEDSTEP > option > After 2H of really hight charge on the processor, it seams not to be > buggy anymore. Am I correct in thinking that it's the /new/ bios version which has disabled Pstate, increased vcore, and broken things, whereas the old one works ok? If so, the BIOS provider would hopefully be interested to learn about the regression. http://marc.theaimsgroup.com/?l=openbsd-tech&m=114982557819634&w=2 > It's working on via C7-D Does Dimitry's patch fix your problem? You've gathered more information than you have presented as a collection; perhaps you could create a report with as much information as you've found out so far - people able to fix this are presumably busy enough they don't have time to chase through various mailing list posts to gather all the information you have. If it's possible to work with the BIOS provider I expect that would be useful too, since they can try reverting the individual changes which would help track things down. Presumably they will need some simple instructions so they can determine whether the problem is occurring. One thought I had: perhaps pstate was disabled as an emergency fix to work-around some linux bug and was done without fully testing which other systems might be affected. Perhaps there is some chance that their fix is incorrect, or perhaps despite being correct, is in some way unusual that is causing problems with speedstep support in some OS. Are the sensors on this board supported? Especially, are they supported both by some OS which works correctly, and some OS which doesn't? If so, it might be informative to look at Vcore and see if it differs. This might be the type of behaviour you could expect if Vcore was too low. (`sysctl hw' on OpenBSD, you'll have to find an equivalent for other OS).
