Bug 57476
Summary: | init q can hang the system requiring a hard reboot | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Don Knott <dknott> |
Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
Status: | CLOSED NOTABUG | QA Contact: | David Lawrence <dkl> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 7.2 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2001-12-17 15:46:22 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Don Knott
2001-12-13 16:23:05 UTC
If the system hangs hard, that indicates a kernel driver problem of some sort, most likely. Well.... unless you kill init.... The Digi Datafire RAS4 BRI card has a kernel module called dgdm that makes the ports /dev/ttyG_0x available. I think when the crash occurs is when there is an active ppp session and I try to do an 'init q' to reread changes to the inittab. I've also found that 'service dgdm stop' doesn't remove the dgdm module and I have to rmmod dgdm before I can do 'service dgdm start'. Its feeling like this may be the dgdm module causing problems. If it only happens on an 'init q' during active ppp sessions I can work around that. Once the box is stable and in production I won't be doing 'init q' all the time. I'll also contact Digi to get their thoughts on their module. System locked up again and I was not making any changes to inittab and did not use 'init q'. I've opened up a case with Digi support to see if they can shed any light on the problem. Digi support recommends installing and using the older gcc compiler. compat-egcs-6.2-1.1.2.16 compat-glibc-6.2-2.1.3.2 They say they have had reports of issues when gcc-2.96 is used. I've done this and will see if the system is stable for the next few days. Ehm that compiler is known to not compile 2.4 kernels well; also using a different compiler for the kernel and modules is a really bad idea ;( Do you have a pointer to the source of the module; I'll have a look http://support.digi.com/support/indexes/linux-dfrasb4.html I had no trouble rebuilding the src rpm with either compiler. I noticed that when I built the rpm with gcc-2.96 that the driver wouldn't unload itself and I had to do an rmmod to remove it. I haven't seen that problem with the older compiler. http://support.digi.com/support/techsupport/unix/linux/rh7xfaq.html The link above is to RH7x specific FAQ. It states that RH7.1 is not supported and that the shipped version of gcc 2.96 is broken. The FAQ also recommends the latest RH 7.2 kernel and source which I have. I've attempted to implement all of Digi's recommended fixes. The system is still unstable and locked up over the weekend. Based upon additional information from Digi, this problem has been found not to be a Redhat bug and is a problem with Digi's drivers not being smp safe. Mail from Digi: I just recieved more info from Digi: "Unfortunately, there are reports of system lock-ups on SMP hardware (not just related to SMP kernel). We have been advised that Engineering will be looking into this matter in January. If you do not have a single processor machine or if you need this resolved in a more timely manner, we will be happy to make arrangements for a product refund." |