[arch-general] mdadm segfaults with kernel 2.6.38.2
Hi folks, I just upgraded to the latest kernel. The /etc/rc.d/mdadm script, which starts mdadm in monitor mode, reports a segmentation fault in mdadm --monitor --oneshot --scan. I also tried to manually start, e.g., mdadm --monitor /dev/md0, and get a segmentation fault there, too. Since this did not happen before the kernel upgrade and mdadm interacts rather closely with the kernel, I suspect that some change in the latest kernel is to blame for this. Did anybody else run into the same problem? Where would I start debugging it? Cheers, Norbert -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
On Monday 11 April 2011 20:58:40 Norbert Zeh wrote:
I just upgraded to the latest kernel. The /etc/rc.d/mdadm script, which starts mdadm in monitor mode, reports a segmentation fault in mdadm --monitor --oneshot --scan.
I also tried to manually start, e.g., mdadm --monitor /dev/md0, and get a segmentation fault there, too.
Since this did not happen before the kernel upgrade and mdadm interacts rather closely with the kernel, I suspect that some change in the latest kernel is to blame for this.
Did anybody else run into the same problem?
Where would I start debugging it?
Downgrade to 2.6.37.5/6 and confirm it's the kernel. Then search for a bug, join the bug report, or file one. I had some really horrible graphics with my ATI Mobility Radeon HD 3650 and open source ati driver since updating to 2.6.38.2. Luckily the latest xorg and newer ati driver is out. I will test it and take it from there. -- Divan Santana
On Monday 11 April 2011 21:32:30 Divan Santana wrote:
On Monday 11 April 2011 20:58:40 Norbert Zeh wrote:
I just upgraded to the latest kernel. The /etc/rc.d/mdadm script, which starts mdadm in monitor mode, reports a segmentation fault in mdadm --monitor --oneshot --scan.
I also tried to manually start, e.g., mdadm --monitor /dev/md0, and get a segmentation fault there, too.
Since this did not happen before the kernel upgrade and mdadm interacts rather closely with the kernel, I suspect that some change in the latest kernel is to blame for this.
Did anybody else run into the same problem?
Where would I start debugging it?
Downgrade to 2.6.37.5/6 and confirm it's the kernel. Then search for a bug, join the bug report, or file one.
I had some really horrible graphics with my ATI Mobility Radeon HD 3650 and open source ati driver since updating to 2.6.38.2. Luckily the latest xorg and newer ati driver is out.
I will test it and take it from there.
Latest updates seem to fix the graphics 100%(hopefully I'm not speaking too soon). Excellent. -- Divan Santana
Divan Santana [2011.04.11 2132 +0200]:
On Monday 11 April 2011 20:58:40 Norbert Zeh wrote:
I just upgraded to the latest kernel. The /etc/rc.d/mdadm script, which starts mdadm in monitor mode, reports a segmentation fault in mdadm --monitor --oneshot --scan.
I also tried to manually start, e.g., mdadm --monitor /dev/md0, and get a segmentation fault there, too.
Since this did not happen before the kernel upgrade and mdadm interacts rather closely with the kernel, I suspect that some change in the latest kernel is to blame for this.
Did anybody else run into the same problem?
Where would I start debugging it?
Downgrade to 2.6.37.5/6 and confirm it's the kernel. Then search for a bug, join the bug report, or file one.
I had this on my to-do list already, but I appreciate the suggestion. Now, the good news is: it's not the kernel, as the same thing happens with the kernel I was running previously: 2.6.37.5. The bad news: it still happens, and I think I know the culprit. mdadm was upgraded along with my kernel upgrade. So occam's razor suggests the new version of mdadm itself is to blame for the segfault. Unfortunately, while I diligently keep old versions of my kernel package, I don't have the previous version of mdadm lying around to investigate this further. Any suggestions? Cheers, Norbert
Norbert Zeh [2011.04.11 2102 -0300]:
Divan Santana [2011.04.11 2132 +0200]:
On Monday 11 April 2011 20:58:40 Norbert Zeh wrote:
I just upgraded to the latest kernel. The /etc/rc.d/mdadm script, which starts mdadm in monitor mode, reports a segmentation fault in mdadm --monitor --oneshot --scan.
I also tried to manually start, e.g., mdadm --monitor /dev/md0, and get a segmentation fault there, too.
Since this did not happen before the kernel upgrade and mdadm interacts rather closely with the kernel, I suspect that some change in the latest kernel is to blame for this.
Did anybody else run into the same problem?
Where would I start debugging it?
Downgrade to 2.6.37.5/6 and confirm it's the kernel. Then search for a bug, join the bug report, or file one.
I had this on my to-do list already, but I appreciate the suggestion. Now, the good news is: it's not the kernel, as the same thing happens with the kernel I was running previously: 2.6.37.5.
The bad news: it still happens, and I think I know the culprit. mdadm was upgraded along with my kernel upgrade. So occam's razor suggests the new version of mdadm itself is to blame for the segfault. Unfortunately, while I diligently keep old versions of my kernel package, I don't have the previous version of mdadm lying around to investigate this further. Any suggestions?
And things got even stranger just now, with a silver lining. The version of mdadm found in [core] is 3.2.1. ABS, on the other hand, still has the old version (3.1.5). Isn't ABS supposed to be the official source tree for the official repos? Maybe I misunderstand the relationship between ABS and the repos. In any case, given that ABS still had the old version, I was able to rebuild the old version of mdadm and downgrade. Voila, it works, with the newest kernel. So the culprit is the new mdadm version. I guess it's time to report the bug upstream and, for now, stick to the old version of mdadm. Cheers, Norbert
On 04/12/2011 03:17 AM, Norbert Zeh wrote:
Norbert Zeh [2011.04.11 2102 -0300]:
Divan Santana [2011.04.11 2132 +0200]:
On Monday 11 April 2011 20:58:40 Norbert Zeh wrote:
I just upgraded to the latest kernel. The /etc/rc.d/mdadm script, which starts mdadm in monitor mode, reports a segmentation fault in mdadm --monitor --oneshot --scan.
I also tried to manually start, e.g., mdadm --monitor /dev/md0, and get a segmentation fault there, too.
Since this did not happen before the kernel upgrade and mdadm interacts rather closely with the kernel, I suspect that some change in the latest kernel is to blame for this.
Did anybody else run into the same problem?
Where would I start debugging it?
Downgrade to 2.6.37.5/6 and confirm it's the kernel. Then search for a bug, join the bug report, or file one.
I had this on my to-do list already, but I appreciate the suggestion. Now, the good news is: it's not the kernel, as the same thing happens with the kernel I was running previously: 2.6.37.5.
The bad news: it still happens, and I think I know the culprit. mdadm was upgraded along with my kernel upgrade. So occam's razor suggests the new version of mdadm itself is to blame for the segfault. Unfortunately, while I diligently keep old versions of my kernel package, I don't have the previous version of mdadm lying around to investigate this further. Any suggestions?
And things got even stranger just now, with a silver lining. The version of mdadm found in [core] is 3.2.1. ABS, on the other hand, still has the old version (3.1.5). Isn't ABS supposed to be the official source tree for the official repos? Maybe I misunderstand the relationship between ABS and the repos.
abs is synchronized once a day -- Ionuț
Ionuț Bîru [2011.04.12 0318 +0300]: [...]
And things got even stranger just now, with a silver lining. The version of mdadm found in [core] is 3.2.1. ABS, on the other hand, still has the old version (3.1.5). Isn't ABS supposed to be the official source tree for the official repos? Maybe I misunderstand the relationship between ABS and the repos.
abs is synchronized once a day
Aaah. Ain't I lucky ;) Thanks for the explanation. Cheers, Norbert
You can also look for it in the Arch Rollback Machine (
http://arm.konnichi.com). For instance, you can find mdadm for x86_64 here:
http://arm.konnichi.com/core/os/x86_64/
On Mon, Apr 11, 2011 at 7:28 PM, Norbert Zeh
Ionuț Bîru [2011.04.12 0318 +0300]:
[...]
And things got even stranger just now, with a silver lining. The version of mdadm found in [core] is 3.2.1. ABS, on the other hand, still has the old version (3.1.5). Isn't ABS supposed to be the official source tree for the official repos? Maybe I misunderstand the relationship between ABS and the repos.
abs is synchronized once a day
Aaah. Ain't I lucky ;) Thanks for the explanation.
Cheers, Norbert
-- -Erik "For me, it is far better to grasp the universe as it really is than to persist in delusion, however satisfying and reassuring." --Carl Sagan
Erik Johnson [2011.04.12 1730 -0500]:
You can also look for it in the Arch Rollback Machine ( http://arm.konnichi.com). For instance, you can find mdadm for x86_64 here:
That's a very useful pointer, which may come in handy in similar situations in the future - thanks. As for mdadm, I'm in touch with upstream to figure out where along the way from 3.1.5 to 3.2.1 things broke. Apparently 3.2.1 makes some unwarranted assumptions about 0.90 md arrays, and the git repository already contains patches to fix this. Cheers, Norbert
Upstream is aware of the issue, which occurs with version 0.90 md arrays. The latest git version fixes the problem. So it's only a matter of waiting for a new release version from upstream for this to trickle into the arch repos. For now I simply keep mdadm pinned on v3.1.5, which is in fact the version currently recommended by upstream unless you need the features introduced in 3.2.1. - Norbert
participants (4)
-
Divan Santana
-
Erik Johnson
-
Ionuț Bîru
-
Norbert Zeh