I am extremely inexperienced with software RAID, so please don't flame me if this message comes arcross as evidence of outright idiocy. I prefer to think the line between idiocy and adventurousness is just very thin. I built a custom kernel using the 2.2.14 source and applying the most recent patch, raid0145-19990824-2.2.11. Although that patch was targeted officially at 2.2.11, it worked fairly well, rejecting only some architecture-specific files related to SPARC and PPC, and the raid0.c module. Since I am not even compiling the raid0.c module and am running on Intel x86, this seemed like a reasonable result. The kernel builds and runs fairly well in most respects that I can see. Besides, it was the most recent source patch at the places mentioned in the HOWTO; is there anything better available? I then used this custom kernel as a replacement on the installation disk for the Debian "Potato" distribution. I put the userland raidtools onto a floppy disk, which I can mount manually after booting. I also wrote a short raidtab onto the floppy which almost exactly follows the example in the HOWTO for a RAID-1 set, using type 0xFD /dev/hda1 and /dev/hdc1 partitions which had been created manually with fdisk. Both /dev/hda and /dev/hdc are identical 30 GB Western Digital drives, partitioned identically. I used mkraid successfully and I can use raidstart and raidstop with no problems. The contents of /proc/mdstat look good. If I allow the initial mirroring to complete, the /dev/md0 device works normally as far as I can tell. It can be mounted, files read and written to it, and so on. However, during the remirroring process, I was able to to do everything successfully prior to mount. During the remirroring process, I can run mke2fs and e2fsck successfully, and e2fsck reports it as clean when that would be expected. However, any attempt to mount the partition during the remirroring process fails out with the unhelpful: Kernel PANIC: B_FREE inserted into queues. This is particularly irritating, since this causes a complete lockup and the remirror starts again from scratch on the reboot. The ext2 fs code seems to be solid. The md0 device and its ext2 fs work fine as long as the remirror is not in progress, or at least I think so. I can mount an ext2 fs floppy disk (which I created as a test) during the remirror of md0 with no trouble. I really have too little experience with software RAID to know what I am looking at here. The kernel panic is not helpful, and it generates nothing by way of stack trace or other information besides the one line message. I am at a complete loss even to guess which subsystem it is coming from, since the queue manager is touched by everything. I have even been wondering if the problem could be hardware, triggered by something like writing to both IDE channels in quick succession or DMA mismanagement. The system in question is a Pentium 166 MHz with 64 MB RAM using an Asus P55TP4N motherboard (upgraded to the latest BIOS), which has the Intel Triton chipset (82371 and 82437) handling the IDE channels. Although the system runs when the mirror is synchronized, this instability during remirror greatly troubles me, and it essentially defeats the whole purpose of using RAID. I also have doubts about whether the system is truly stable in this configuration even with the mirror synchronized, or whether it is working by coincidence and some set of circumstances or sequence of events will cause a kernel panic during normal operation. Can you give me any insight on this? I am very new to software RAID. -- Mike