>>> On 1/6/2009 at 3:51 PM, Berry van Sleeuwen <berry.vansleeu...@xs4all.nl> wrote: -snip- > Just for my good understanding (and for some input tomorrow at our next > meeting). Suppose we would be able to open a service request, what would > be the chance a kernel bug can be fixed through a service request?
For a true software bug (and when the program itself it telling you it's a bug, it's hard to argue that it's not), assuming the proper support contract is in place, a fix will be created and a PTF sent to the customer for testing. The major Linux distribution providers have a significant amount of kernel development skills on staff. Many of the heavy hitters in Linux kernel development work directly for the distribution providers. > Based > on the discussions on the aio.c my guess would be that a kernel fix > would be difficult to get implemented, especially when a quick result is > expected. Am I correct when I expect that the service would be close to > an advice like changing specific parameters and/or install a newer > kernel or patch? If you're not already at the latest kernel, then most likely you would be asked to upgrade to that first and test. If the problem still exists, then a PTF would (eventually) be produced. You didn't provide the specific kernel RPM version in your first note, so I don't know if that would apply to you or not. The most current version is 2.6.5-7.315. In general, parameter changes may be requested, if you're not following the recommendations from the ISV that certified the software. If you are, and there is a bug, we will work to fix it. In many cases, PTFs are provided that we know won't fix the problem, but might provide more clues as to just what is happening to cause the problem. The speed with which that happens is dependent on many factors, such as severity and business impact to the customer, how difficult it is to figure out what's wrong, getting the customer to test new PTF packages, etc. For this particular piece of code, the relatively long resolution times appear to be mostly related to trying to figure out exactly what is wrong, due to the complexity of the code, and being able to get the affected customers to test. > (Note that this is in no way to you personally, I > expect kernel changes to be part of the kernel development team so any > change in that part is outside the scope of any company that provides > support. The problem is how to convince the upper level to view it the > same way. As Alan did suggest, input for a MER.) Once a fix has been created, then attempts are made to get that fix accepted in the mainline kernel source. If that is not successful, then the Linux distribution provider is responsible for maintaining that fix outside the official tree, until the release is at end of life. It's part of what you pay for when you buy support. > Do you know by any chance what button to push for AIO in Oracle? I know > that we did cover that when the server was installed 4 years ago but I > didn't do that part myself. IIRC it was asynch_IO=yes or some parameter > like that. Correct? Sorry, no I don't. > Is there any guess as to what performance penalty this disable would > give us? The server does hit it's limits quite often so I expect this > question to be the next one. I would have no clue. The decision will have to come down to what's better for your company, taking the performance hit, or living with the bug. Mark Post ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
