It is possible that the problem is a result of the raid code not beeing PPC
friendly when concerning byte boundries.

Open up linux/include/linux/raid/md_p.h
At line 161 you should have something ressembling the following

        __u32 sb_csum;          /*  6 checksum of the whole superblock
*/
        __u64 events;             /*  7 number of superblock updates
(64-bit!)  */
        __u32 gstate_sreserved[MD_SB_GENERIC_STATE_WORDS - 9];

Try swapping the __u32 sb_csum and __u64 events around so that it looks like

        __u64 events;             /*  7 number of superblock updates
(64-bit!)  */
        __u32 sb_csum;          /*  6 checksum of the whole superblock
*/
        __u32 gstate_sreserved[MD_SB_GENERIC_STATE_WORDS - 9];

This should fix the byte boundry problem that seems to cause a few issues
on PPC systems.  This problem and solution was previously reported by
Corey Minyard whom notated that the PPC is a bit more picky about byte
boundries then the x86 architecture.

"Kevin M. Myer" wrote:

> Hi,
>
> I am running kernel 2.2.14 + Ingo's latest RAID patches on an Apple
> Network Server.  I have (had) a RAID 5 array with 5 4Gb Seagate drives in
> it working nicely with 2.2.11 and I had to do something silly, like
> upgrade the kernel so I can use the big LCD display on the front to
> display cute messages.
>
> Now, I seem to have a major problem - I can make the array fine.  I can
> create a filesystem fine.  I can start and stop the array fine.  But I
> can't reboot.  Once I reboot, the kernel loads until it reaches the raid
> detection.  It detects the five drives and identifies them as a RAID5
> array and then, endlessly, the following streams across my screen:
>
> <[dev 00:00]><[dev 00:00]><[dev 00:00]><[dev 00:00]><[dev 00:00]><[dev
> 00:00]><[dev 00:00]>
>
> ad infiniteum and forever.
>
> I have no choice but to reboot with an old kernel, run mkraid on the whole
> array again, remake the file system and download the 5 Gigs of Linux and
> BSD software that I had mirrored.
>
> Can anyone tell me where to start looking for clues as to whats going
> on?  I'm using persistent superblocks and as far as I can tell, everything
> is getting updated when I shutdown the machine and reboot
> it.  Unfortunately, the kernel nevers gets to the point where it can dump
> the stuff from dmesg into syslog so I have no record of what its actually
> stumbling over.
>
> Any ideas of what to try?  Need more information?
>
> Thanks,
>
> Kevin
>
> --
>      ~        Kevin M. Myer
>     . .       Network/System Administrator
>     /V\       ELANCO School District
>    // \\
>   /(   )\
>    ^`~'^

Reply via email to