Well, I'm still can't find out what was broken there...
A couple of negative info: bootloader isn't guilty,
initrd is NOT corrupted: when 2.4.13 is booted with 'noinitrd', I can dump
initrd 'cat /dev/initrd > file' and it's perfectly mountable via loop device
(good, usable minix fs there). Same with gzipped minix - good fs
after ungzipping. These two even compare ok (no difference).
I presume this means that initrd is not tampered with in RAM.
Something bad must be happening when initrd is copied to ramdisk
or when ramdisk is mounted. Both seem unlikely because
rd.c diff between 2.4.10 and .12 is tiny (see below)
and ramdisk mount is tested from userspace (ok),
but something *must be* broken there or I'm doing something stupid.
My test minix.gz is here (btw: it's unmodified slackware one,
~1.4 meg):
http://port.imtp.ilyichevsk.odessa.ua/linux/vda/minix.gz
I'll be glad if anyone will try to reproduce initrd problem
with 2.4.x, x>=12 with this image.
Andreas, can you give me your image for testing?
-- vdadiff -u --recursive linux-2.4.10/drivers/block/rd.c linux-2.4.12/drivers/block/rd.c --- linux-2.4.10/drivers/block/rd.c Sun Sep 23 14:44:37 2001 +++ linux-2.4.12/drivers/block/rd.c Mon Oct 8 16:25:14 2001 @@ -276,7 +276,6 @@ if (!Page_Uptodate(page)) { memset(kmap(page), 0, PAGE_CACHE_SIZE); kunmap(page); - flush_dcache_page(page); SetPageUptodate(page); }
@@ -301,8 +300,11 @@ kunmap(page); bh_kunmap(sbh);
- if (rw != READ) + if (rw == READ) { + flush_dcache_page(page); + } else { SetPageDirty(page); + } if (unlock) UnlockPage(page); __free_page(page); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/