IRC channel logs


back to list of logs

<almuhs>hi, I have a question
<almuhs>are there any way to test my gnumach code without before compile It in Hurd?
<almuhs>**are there any way to test my gnumach code before compile It in Hurd?
***Server sets mode: +nt
***Server sets mode: +nt
***Server sets mode: +nt
***Server sets mode: +nt
***dingenskirchen1 is now known as dingenskirchen
<AlmuHS>damo22: tonight I uploaded to my repository a new commit with a draft of ACPI APIC simplified
<AlmuHS>in the branch smp-new
<AlmuHS>I have not tested It in gnumach yet
<AlmuHS>This code is not fully cleaned yet. I have to remove some garbage. But compiles
<AlmuHS>I have to fix the naming. I don't know what can be the most appropriate
<AlmuHS>this afternoon I will try to run It in gnumach
<AlmuHS>youpi: the last version of Debian GNU/Hurd doesn't stop the booting if filesystem is damaged
<AlmuHS>I have to reinstall my VM because my filesystem is corrupt by this reason
<damo22>just mount it with loop
<damo22>and e2fsck it from outside
<AlmuHS>The most comfortable way was to use the "emergency" console, which Mach usually opened when the filesystem check fails
<AlmuHS>but, in the latest versions, this console has disappeared
<damo22>are you in linux with hurd vm
<damo22>where is disk ?
<AlmuHS>in a file
<AlmuHS>called hurd.img
<AlmuHS>in my home directory
<damo22>losetup -P ~/hurd.img /dev/loop0
<damo22>fdisk /dev/loop0pX
<damo22>or e2fsck /dev/loop0pX
<damo22>sorry fdisk is wron
<damo22>then when youre finished with it, losetup -D
<AlmuHS>my system doesn't find /dev/loop0
<damo22>sudo losetup -P -f --show ~/hurd.img
<AlmuHS>this returns /dev/loop0
<damo22>so then you can access /dev/loop0pX
<damo22>like a disk
<damo22>but dont do it while hurd is powered
<damo22>so you can fix the system in linux
<AlmuHS>but /dev/loop0p0 doesn't exists
<damo22>try 1
<damo22>ls /dev/loop0*
<AlmuHS>only show /dev/loop0
<damo22>what about fdisk /dev/loop0
<damo22>can you see partitions
<almuhs>the device doesn't have any known partition table
<damo22>file /dev/loop0
<almuhs>/dev/loop0: block special (7/0)
<damo22>did you use -P
<damo22>check man losetup
<damo22>got to go
<almuhs>yes, I used -P
<almuhs>losetup: /dev/loop0: error configuring loop device: ioctl not appropiated to the device
<almuhs>losetup: /dev/loop5: failed to set up loop device: Inappropriate ioctl for device
<almuhs>sudo losetup -P ~/hurd_qemu/hurd.img /dev/loop5
<almuhs>losetup: /dev/loop5: failed to set up loop device: Inappropriate ioctl for device
<almuhs>maybe hurd.img is not compatible. I'm not sure if is possible to access to a qcow file as this way
<almuhs>damo22: finally, I got this using this tutorial
<gnu_srs> /var/tmp/gdb-8.2.1/gdb/thread.c:266: internal-error: thread_info* add_thread_silent(ptid_t): Assertion `inf != NULL' failed.
<gnu_srs>almuhs: As root /sbin/losetup -o 1048576 /dev/loop0 hurd.img; e2fsck -y /dev/loop0; losetup -d /dev/loop0
<almuhs>gnu_srs: finally, I solved the problem from qemu
<almuhs>with this:
<gnu_srs>offset is calculated from fdisk -l ...hurd.img * 2048 62500863 ... 2048*512=1048676
<youpi>gnu_srs: that works only for raw images, almuhs has a qcow image
<almuhs>I'm testing my latest smp commit. Mach hangs just after start the booting
<almuhs>these are the commits:
<almuhs>youpi: do you know if phystokv() macro works if It's called after paging configuration?
<almuhs>like this:
<youpi>almuhs: it doesn't care about paging, only about segmenting
<almuhs>then, not works
<youpi>it shall *not* be called before segmentation is set up, and it *shall* be called after segmentation is set up
<youpi>Mmm, though it seems c_boot_entry calls it very early
<gnu_srs>youpi: OK, got it.
<youpi>possibly it assumes that grub has set up segmentation
<almuhs>I'm calling this function here:
<youpi>almuhs: print the pointers, to make sure what is happening
<almuhs>I'm printing the pointers, but crash before
<almuhs>I think that the phystokv() is failing, and cause a kernel panic
<youpi>I don't see how it could be failing
<youpi>did you look what it does?
<youpi>do you really need to call acpi_setup that early?
<almuhs>wait, I go to compile the default upstream gnumach
<almuhs>to be sure that the problem is mine
<youpi>almuhs: at worse, define ENABLE_IMMEDIATE_CONSOLE
<youpi>that'll just throw the text on the vga memory
<almuhs>in what file? I don't remember
<youpi>grep will tell you
<almuhs>upstream gnumach runs well
<almuhs>then the problem is in my code
<almuhs>disabling acpi_setup() call the code works. So the problem is there
<youpi>really, enable the immedaite console
<youpi>you'll then be able to just put printf() to know what is reached
<youpi>no use trying to guess when you can just print it
<almuhs>ok, I go to enable It
<almuhs>in i386/
<youpi>if that's the only place that talks about defining it, it cannot be anywhere else
<almuhs>ok, XD
<almuhs>now I see the kernel panic
<youpi>and you have the eip to know which instruction that is
<almuhs>the fails in in memcmp
<almuhs>c10083a4: f3 a6 repz cmpsb %es:(%edi),%ds:(%esi)
<almuhs>but I don't find who calls to this memcmp
<youpi>you can put printfs to see the progress
<almuhs>this is so strange. After compile with a few changes, the kernel panic has the same eip
<almuhs>really, there are exactly the same registers values
<almuhs>ok, the code reach rsdp
<almuhs>the code reach rsdt address, but It seems that crash before returns It
<almuhs>in fact, the kernel page fault is in the same rsdt address
<almuhs>youpi: I suspect that the fail is in this line
<almuhs>I suspect that rsdt address is unreachable (or simply, the virtual address is different that physical address)
<almuhs>fuck... now Hurd freeze after load exec server... I thank that this problem was solved many months ago
<almuhs>youpi: finally, I confirm that the kernel crash is a page fault when this try to access to rsdt
<almuhs>curious: I have refactor the code to remove most global variables, and now It boots after ext2fs
<almuhs>this is the code now:
<youpi>almuhs: then print the address
<youpi>to make sure what is happening
<youpi>possibly you got an erroneous address somehow
<youpi>almuhs: to get a backtrace, pass --enable-kdb to configure
<almuhs>I'm refactoring some functions yet. After this I will try again
<almuhs>in my qemu script I have --enable-kdb
<youpi>qemu script ?
<almuhs>I test the code in a qemu VM
<almuhs>which I boot from a script
<almuhs>oh, excuse me
<almuhs>kdb, not kvm
<almuhs>ok, then I will add this option after
<almuhs>fixed a couple of values, back to crash in the same place again
<almuhs>after find rsdt, I think
<almuhs>yes, I confirm that the crash is in the same step than before: trying to access to rsdt address
<almuhs>I suspect that the virtual address is not correct. phystokv() doesn't works after paging
<almuhs>by any unknown reason, It's possible to access to RSDP with its physical address. But It's not possible do the same with RSDT
***DNS is now known as snd
<youpi>almuhs: very large addresss are indeed not supported by the gnumach segmentation
<youpi>since the shift is by 0xC0000000
<youpi>so you'd need temporary maps to access that
<almuhs>damo22: I was testing my ACPI code in gnumach
<almuhs>The code seems to find RSDP, but crash when tries to access to rsdt
<youpi>(it's too far in addresses)
<almuhs>yes, I suspect this
<almuhs>but, how can I solve this?
<youpi>your prints show it
<youpi>like I said, you'll need temporary maps
<almuhs>yes, the print shows that is away from kernel space
<almuhs>what is the function for this? I don't remember
<almuhs>and other question. what place do you think that is better to add the caller for this function?
<almuhs>I have just move It here:
<almuhs>just after i386at_init(). But I'm not sure about can be better call It before
<almuhs>in a previous function or line