Re: 64-bit userspace root file system for hppa64

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/11/23 13:38, Helge Deller wrote:
On 12/11/23 18:26, Guenter Roeck wrote:
On 12/11/23 07:53, Helge Deller wrote:
On 12/10/23 22:59, Guenter Roeck wrote:
On 12/10/23 13:42, Helge Deller wrote:
[ ... ]> I actually don't know if null-bytes are transferred.
But ext4 reports CRC errors, so I added this hunk to the Linux kernel:

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index d7732320431a..9b12fbd44e06 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -4732,6 +4736,9 @@ struct inode *__ext4_iget(struct super_block *sb, unsigned long ino,
         if (ret < 0)
                 goto bad_inode;
         raw_inode = ext4_raw_inode(&iloc);
+// printk("raw_info  provided %px %x\n", &raw_inode->i_checksum_lo, raw_inode->i_checksum_lo);
+// printk("  iloc->bh->b_data %px  iloc->offset %lx\n", iloc.bh->b_data, iloc.offset);
+if (raw_inode->i_checksum_lo == 0) asm(".word 0xfffdead0");

The last line immediately stops qemu if the checksum is zero.
I start qemu with
  ./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0 -kernel vmlinux  -append "root=/dev/sda5 console=ttyS0 single earlycon=pdc"  -serial mon:stdio -smp cpus=3  -machine C3700  -nographic  -snapshot -device am53c974,id=scsi -device scsi-hd,bus=scsi.0,drive=d0

qemu aborts with the am53c974 driver.
If I use exactly the same command, but with the lsi53c895a driver instead of am53c974, it boots correctly.

Any other idea?


Does your code use scatter-gather DMA ?

Which code? The kernel which mounts the ext4 filesystem?


Seabios. Sorry, I thought your problem was with that.

Yes and no.
My main intention was to test with the Linux kernel primarily.
If this works, then it's easier to test the SeaBIOS code too.

If so, that might explain the problem.
I don't think the qemu code implements that properly. I don't mean the MDL version,
that isn't implemented at all. I mean the non-MDL version, where a single SCSI
command requires multiple DMA transfers which have to be set up one by one.

Is there any way I could test, e.g. by disabling SG ?


No idea, but that makes me wonder if ext4 and other file systems somehow trigger SG
operation while ext2 doesn't. I'll do some debugging along that line.

Ok, thanks!


Nothing conclusive. ext2 always passes, ext4 and btrfs sometimes pass, sometimes
fail. They also sometimes fail with lsi53c895a, so that isn't the determining
factor. I always get the "Unaligned handler failed" error.

Guenter





[Index of Archives]     [Linux SoC]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux