Red Hat Bugzilla – Full Text Bug Listing
|Product:||Red Hat Enterprise Linux 3||Reporter:||Joe Griffin <joe.griffin>|
|Component:||glibc||Assignee:||Jakub Jelinek <jakub>|
|Status:||CLOSED WONTFIX||QA Contact:||Brian Brock <bbrock>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-10-30 05:30:39 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Joe Griffin 2004-02-25 13:42:34 EST
Description of problem: I just installed RedHat WS release 3 (Taroon Update 1) on my IA64 with McKinely CPUs. I am having 3 problems: 1. I get a message stating that only 2 CPUs are supported (So I removed 2; I had 4) 2. I get lots of messages in /var/log/messages of the form: Feb 23 14:20:39 ia647 kernel: blk: queue e00000007f3eae30, I/O limit 17592186044415Mb (mask 0xffffffffffffffff) What do these mean? 3. I run MSC.Nastran (which worked find with the hardware was running version 2. 1) and for some large jobs I get: ** BUS signal ** This error is repeatable. I am not sure what the problem is related to. I have tried removing 2 CPUs, I removed memory (from 12Gb to 4 Gb), I have tried chang ing partions, file systems types (ext3/ext2) but I still get this error. Again, these jobs worked find in version 2.1. Version-Release number of selected component (if applicable): Red Hat Enterprise Linux WS release 3 (Taroon Update 1) How reproducible: Very reproducable. Steps to Reproduce: 1. I run MSC.Nastran V2004.... I understand that RedHat may not be able to do this step. I am hoping that the three symptons I have given will be enough. Actual results: ** BUS signal ** Expected results: No "BUS SIGNAL" Additional info: Perhaps the problem was that this code was built w/ the old GLIBC. It is build "Dynamically" as far as glibc goes, so I did not expect a problem. Do I need to rebuild the code on RedHat WS 3?
Comment 1 Ulrich Drepper 2004-09-28 07:07:23 EDT
The first problem is likely a hardware problem. One of my machines shows only three processors. The second problem is a kernel/hardware issue. You would have to file an appropriate kernel bug. The last issue can be anything. It is more likely to be an application problem. glibc does not simply generate SIGBUS signals. In any case you cannot get further help analysing this problem since even if we would have that binary, you cannot expect us to debug 3rd party binaries we konw nothing about. If you have some more information about the crash, post it here. Otherwise I'll close the bug soon.
Comment 2 Jakub Jelinek 2004-10-30 05:30:39 EDT
If you have some more info, please reopen.