On Mon, 2006-07-10 at 15:10 -0400, Rich Johnson wrote: > On Jul 10, 2006, at 1:16 PM, Ron Johnson wrote: > > >> [...snip...] > >> Anyway, the problem goes away with a 2.6 kernel. This is with no > >> changes to BIOS or any of the package configurations. This > >> gives _me_ an acceptable solution....for now. > > > > What do you mean "for now"? > > I mean, until I either understand what's going on, or make my peace > with it. It also raised a red-flag about performance under load. I > just don't like ignoring red flags.
Are you a very proficient C programmer? What I am getting at is, the only way you are going to get to the bottom of this is to compare the drivers code in 2.4 and 2.6. Then also look at all the includes and defns and libraries relied upon. You have to realize, that the 2.4 target compiler (might have changed now) was GCC 2.9x.x. And go look at what it was compiled with. Also check the version of GLIBC that was the target. Take a look at which compiler version and glibc version it was compiled with. Sometimes... things just change like that. If the 2.4 kernel was offered in Sarge you would have never seen it. > >> ... there are those nagging doubts. Surely I'm not the only one > >> who's seen such behavior. From a community perspective it's > >> troubling to see a basic, no-frills, stable installation on a > >> name-brand machine produce such horrible results. Nagging doubts are a good thing to have, except for when working with things that are "old news" being as 2.4.27 is indeed two years old, even though Debian backports many fixes... not all are clean enough to pas the bar. Nor are some changes back-portable... being as they change things so horribly that they cause more problems than they fix. > > Maybe NCR changed at some point, but I do know that they were always > > hot for *highly* customized systems. "Added value", it's called. > > The mfgr is NEC, not NCR. Yeah, and I have a Digital Alpha 2100A sitting here right now beside me, that could be called a "Digital/DEC/Compaq/HP Alpha EV45 333MHz 2MB ONBOARD Cache, Alpha Sable 2100/A/B RISC based computer". And for the record, I believe NEC and NCR are now the same company, rather than two separate entities of a holding company. > > The fact that the 2.6 kernel fixes it strongly suggests to me that > > the PG350 *is* such an oddball, where a work-around was only put > > into 2.6. > ...or its could be symptomatic of a race condition, which (under > light loads) fails in 2.4 but succeeds in 2.6. Under heavier loads, > who knows? All-in-all I much prefer affirmative identification of > problems. Wow, the Indy 500 inside the 2.4 Kernel... Nice touch there. See my previous explanation of targets and so on. > And THAT's why I inquried about diagnostics in my first post. I'd > like to verify that the problem doesn't recur. I'd hate to tell you, that your problem though not unique, is symptomatic of code re-factoring in progress on a live tree. There is always code-clean-up, performance-rewrites, standardization efforts going on in the Linux kernel, and Debian... and many other project you are relying on for your free OS. You need to either join in and help fix the stuff, or fill out bug reports or make documentation changes or submit patches to fix things. That is really the only way you are going to make sure this doesn't reoccur. > > > >> It's shaken > >> my confidence that the problem will not reappear at the most > >> inopportune time. It has shaken your confidence... wow, then why the heck are you still using Windows in the first place? Those kinds of unexpected results are being fixed on Patch Tuesday every month by them... or are you hacking (read as programming) Windows as well. > > Oh, puh-leeze. Mobo, chipset and card makers all do some pretty > > weird shit, and it's not easy for Linux to handle every combination > > of custom chipsets. > > I would hope it does at least as good a job as Windoze on the same > machine. Sir, here is where I draw the line. Windows has much better Vendor support for drivers. Where you come from, you cannot comprehend that most of the work odne to make the Linux kernel work has been watching things work and break to fix them, watch again, fix more. Ore reverse engineer the binary drivers to work the function out of them. > Hmm..is there a utility to report the chipset/driver config, as > resolved by the kernel? Is there a way to get a report of the > scheduler's activity? They are called Developer's tools, and running things with debugging symbols not stripped. That's where the "are you a good C programmer?" came in. -- greg, [EMAIL PROTECTED] The technology that is Stronger, Better, Faster: Linux Use Debian GNU/Linux, its a bazaar thing NOTICE: Due to Presidential Executive Orders, the National Security Agency may have read this email without warning, warrant, or notice, and certainly without probable cause. They may do this without any judicial or legislative oversight. You have no recourse nor protection.
signature.asc
Description: This is a digitally signed message part
