Am Montag, 17. April 2006 10:49 schrieb Blue Swirl:
Hi!
This command fails when installing kernel and modules:
qemu-system-sparc -kernel vmlinux-2.6.11+tcx -cdrom
debian-30r4-sparc-binary-1.iso -hda hd -initrd debian-30r4-sparc.initrd
-nographic -append 'cdrom ramdisk_size=16384 devfs=mount
swapper(1): Oops [#1]
Which initrd did you use?
It's the file
/dists/stable/main/disks-sparc/current/images-1.44/root.bin
as specified by /boot/silo.conf, from debian-30r4-sparc-binary-1.iso.
_
Express yourself instantly with MSN
Then I tried to track down this problem with gdb and strace. But
unfortunately, both are segfaulting, too. This makes debugging somewhat
harder... Now, I'll try to analyze the core files of the crashing programs
to
get an idea what's going wrong. Or do you have any idea? What's the
difference
Am Dienstag, 11. April 2006 21:21 schrieb Blue Swirl:
Hi!
Great work! Now the Debian 3.0r4 installer with 2.6.11+tcx kernel almost
finishes. Performance is also much better.
I tried to boot a deb-bootstrapped SPARC image. But the first executed script
segfaults when executing another command
The attached patch is an updated version of my previous patch. Now it
applies
cleanly to cvs head and the read and write performance is increased.
Great work! Now the Debian 3.0r4 installer with 2.6.11+tcx kernel almost
finishes. Performance is also much better.
There is some problem with
Am Freitag, 7. April 2006 17:44 schrieb Blue Swirl:
Hi!
The attached patch is an updated version of my previous patch. Now it applies
cleanly to cvs head and the read and write performance is increased.
regards,
Jörg
--- esp.c 2006-04-10 14:51:37.0 +0200
+++ esp.c.new 2006-04-10
Am Freitag, 7. April 2006 17:44 schrieb Blue Swirl:
Hi!
Maybe this patch helps?
The attached patch is an updated version of your patch. With whis patch I was
able to copy files from one directory to another on a disk image. After
unmounting the image, e2fsck reported no errors on this image.
Thank you for the excellent analysis of the problem! Looks like Qemu doesn't
handle the case where DMA length and SCSI length are not equal.
Until here, the addresses are subsequent. Then the next address is much
lower:
So Linux splits the transfer into two parts to use two separate pieces
Am Freitag, 7. April 2006 17:44 schrieb Blue Swirl:
Hi!
Thank you for the excellent analysis of the problem! Looks like Qemu
doesn't handle the case where DMA length and SCSI length are not equal.
Exact.
So Linux splits the transfer into two parts to use two separate pieces of
buffers.
Am Mittwoch, 5. April 2006 19:36 schrieb Blue Swirl:
Hi!
Today I did some more tests to determine, what's going wrong. At first, Linux
flushes the page entries for the 14 buffers that are to be written to disk:
IOMMU: page flush f001c000
IOMMU: page flush f001d000
IOMMU: page flush f001e000
Am Dienstag, 4. April 2006 21:27 schrieb Joerg Platte:
Hi!
To find this problem, I enabled debugging in the esp.c file and printed the
mapped address (after iommu mapping). In some cases the mapped address is
zero:
ESP: DMA address 0beb8000
ESP: DMA address
I didn't find a manual
To find this problem, I enabled debugging in the esp.c file and printed
the
mapped address (after iommu mapping). In some cases the mapped address
is
zero:
ESP: DMA address 0beb8000
ESP: DMA address
I didn't find a manual of the SBUS IOMMU. But if I understand the contents
of
Am Mittwoch, 5. April 2006 19:36 schrieb Blue Swirl:
Hi!
I don't have any better documentation either, I just coded against what
Proll and Linux expect. But the theory of operation is simple. Much like
OK, I thought I was just too stupid to find good documentation :-)
how the MMU translates
Am Mittwoch, 5. April 2006 19:36 schrieb Blue Swirl:
Hi!
The DMA controllers for both ESP and Lance are within the same page. This
means that in Qemu, DMA controller register accesses for either of them go
to just one of these. It just happens to work, but maybe this causes the
problem. You
14 matches
Mail list logo
