Bug 40586
| Summary: | Crashes when using software RAID on alpha | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Chris Adams <linux> | ||||||
| Component: | kernel | Assignee: | Phil Copeland <copeland> | ||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Brock Organ <borgan> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 7.3 | ||||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | alpha | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2001-05-30 21:51:11 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: | |||||||||
| Attachments: |
|
||||||||
|
Description
Chris Adams
2001-05-14 21:00:40 UTC
Created attachment 18331 [details]
ksymoops output
I am still seeing this with RAID1 on RC1. I'm attaching another decoded oops (this one shows that the kernel was in raid1_read_balance when the oops happened). Created attachment 19632 [details]
Oops with RAID1 with kernel 2.4.3-7
I am not seeing this behavior with our AS1000 test machine, and so we haven't yet reproduced your behavior ... :( what SRM level are you running? I'm running SRM V5.7-80 Mar 27 2000 09:43:35. I'm not sure why this was changed to anaconda instead of the kernel. I have this trouble after install as well (that's where the oops came from). With RC1, I installed without RAID and then remade my /usr/local partition with RAID1. That is where the second oops came from. I've changed it back to kernel component, Part of your issue above is that you get an oops trying to install with RAID devices, so I filed under anaconda ... Here are my machine details: AS1000 5/400 - Alpha ev56 mikasa 400 Mhz; 21164A-1 400 Mhz w/128 Mb; SRM console: v5.4-104; ARC console: v5.68 to be pedantic in reproducing your problem would require taking the SRM level differences into account ... we have seen SRM levels have similar effects in previous releases ... :( Mine is an AlphaServer 1000A 5/300 EV5 Noritake (actually Noritake-Primo) 300MHz w/512MB RAM. One thing that I thought about trying (since you suggest that firmware can matter) is to compile a kernel for Noritake-Primo instead of generic. Do you think that would change anything? One other weird thing I've noticed is that "shutdown -r now" does not end up rebooting. It gets back to the firmware, and then I get (repeatedly): (boot dka0.0.0.2000.0 -flags 0) failed to open dka0.0.0.2000.0 until I hit ^C. If I then type "boot dka0.0.0.2000.0 -flags 0" it restarts and boots okay. I was going to try different firmware, but I'm running the latest version for this platform. I'm open to any suggestions or ways to nail down what is happening. |