|
Bugzilla – Full Text Bug Listing |
| Summary: | dac960 - after rebuild status rimains in "ALERT" | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | carlo menozzi <scs> |
| Component: | Kernel | Assignee: | Chris L Mason <mason> |
| Status: | VERIFIED WONTFIX | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | hare |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | i386 | ||
| OS: | SuSE Linux 10.0 | ||
| Whiteboard: | |||
| Found By: | Customer | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
carlo menozzi
2005-11-28 07:47:24 UTC
thank you for your bug report. i agree that it would be a bug if the controller still displays a status of "alert" even after a successful rebuild. but why do you think it is a bug that the rebuild process isn't "visualized"? in which way did 2.4 visualize the rebuild process? The thing is that if the rebuild process is not visualized what happens is that if there is a hardware problem and the process is blocked I cannot see that it is blocked and I'm still waiting for the process to end. As the process in some cases takes hours, I could be waiting for hours without knowing that the process is blocked due to hardware problems. In fact this has actually happend to me. I substituted what I thought was a new disk but in fact did not work. I was waiting for hours for the process to end when instead it was blocked due to the disk that was faulty. So what I did that time is that instead of using the Linux software, I used the software which is internal to the controller and this permitted me to see that the rebuild was blocked. The version 2.4 showed the percentage of where the rebuild process was at so that I could follow the process exactly. Thanks I looked through the code, and this makes sense, at least if your description is complete. You disconnect a drive, and then initiate a rebuild, which proceeds correctly. However, you never re-connect the drive! So the status remains as ALERT; this will only revert if no drives are critical, failed or offline. Until you re-add the drive, you'll still be missing one though. Do you in fact re-add the drive? If so, at what step and how? The progress bar is not displayed for more recent versions of the DAC960 firmware, which no longer exports this bit of information to the kernel, so this can no longer work. We won't/can't fix this. Perhaps I did not explain things well. When the drive is failed, we switch off the PC, we substitute the failed drive with a new drive, we switch the machine on again and initiate a rebuild again. Therefore we DO re-connect the drive. The problem is also that at the end of the rebuild the status remains in ALERT and if we want it to return to OK, we need to switch off the machine and then switch it on again. Another thing - its very useful to be able to visualize the progress bar when the progress itself lasts more than 30 minutes. Regarding what you say about the progress bar not being diplayed for more recent versions of the DAC960 firmware, its not our case because we use AC170,AC160,AC352 controllers and with kernel 2.4 the progress bar is displayed perfectly. Ihno, you're taking care of storage features. Could you please decide how important the dac960 is for SLES10/SLES9? Is this a RESOLVED WONTFIX or do we need to reproduce locally & fix? In my opinion it is VERY IMPORTANT to fix this bug because normally Mylex controllers are installed in important servers. And these types of servers are usually switched on 24 hours a day. Unfortunately, the DAC960 is not one of the cards we explicitly support. We don't have sufficient customer demand to have the cards on hand in house, or support contracts with partners in place that require the card. This bug is also against SL10.0, where we don't provide the level of support needed to dive into the driver and make the required modifications. Closed. |