Hello, It's strange. I thought the problem doesn't exist any more after I made some changes in the kernel. Are you using the latest gnumach in the master-user_level_drivers branch?
Best, Zheng Da On 8/30/10 12:15 AM, Diego Nieto Cid wrote: > Hello, > > Short story: something is clearing kernel_page_dir. > > Long story follows. :) > > On Wed, Jun 09, 2010 at 08:24:55AM +0200, Samuel Thibault wrote: >> >> These are correct. So that must the the pagetable that is incorrect. >> Check out cr3 and such. >> > > While trying DDE I came across this problem too. I run a few tests and > your guess is apparently correct: > > +-------+--------+--------+---------+------+-----+---------+ > | Test# | eip | *esp | kpd | kpd' | CR3 | CR3' | > + ------+--------+--------+---------+------+-----+---------+ > | 1 | 107e92 | 1436c7 | --- | --- | --- | --- | > +-------+--------+--------+---------+------+-----+---------+ > | 2 | 1051f9 | --- | 1371000 | --- | kpd | 2e8f000 | > +-------+--------+--------+---------+------+-----+---------+ > | 3 | 107e92 | 1436c7 | 1371000 | 0 | kpd | 219a000 | > +-------+--------+--------+---------+------+-----+---------+ > | 4 | 107e92 | 1436c7 | 1371000 | 0 | kpd | 2d18000 | > +-------+--------+--------+---------+------+-----+---------+ > > Where kpd is the contraction of kernel_page_dir, ' means after the > trap and --- that there is no available information. > > Meaning of some addresses: > > # addr2line -e /boot/gnumach 0x107392 0x1436c7 0x1051f9 > ...gnumach/i386/i386/spl.S:217 > ...gnumach/i386/i386at/interrupt.S:40 > ...gnumach/i386/i386at/kdasm.S:113 > > CR3 value was taken from qemu's monitor console: > > (qemu) info registers > > And this is where kpd was read from: > > # nm /boot/gnumach | grep kernel_page_dir > 001aa2b0 B kernel_page_dir > > All the test were done by running the following commands: > > # settrans -acfgp /servers/drivers/eth0 /hurd/dde/dde_ne2k_pci > ... > # settrans -acfgp /dev/eth0 /hurd/dde/devnode eth0 \ > > -M /servers/drivers/eth0 > ... > # settrans -acfgp /servers/socket/2 /hurd/dde/pfinet -i /dev/eth0 \ > > -a 10.0.2.16 -g 10.0.2.2 -m 255.255.255.0 > ... > # wget www.google.com > --2010-08-30 02:18:19-- http://www.google.com/ > Resolving www.google.com... <<<<<trap point > > During the first test I collected the values of the registers. > They are similar to what Zheng Da showed before. > --------- > Kernel General protection trap, eip 0x107e92 > kernel: General protection (13), code=25a > Stopped at 0x107e92: ret > db> trace > 0x107e92(646565,656b6f70,6761705f,66007365,5f656572) > > no memory is assigned to address 6c610077 > db> show registers > cs 0x8 > ds 0x10 > es 0x10 > fs 0x10 > gs 0x10 > ss 0x10 > eax 0x5 > ecx 0x1c > edx 0x5 > ebx 0x44520 > esp 0x1a9f20 > ebp 0x12dbd1c > esi 0x44560 > edi 0x3c > eip 0x107e92 > efl 0x297 > db> examine 0x1a9f20 > 1436c7 > db> > --------- > > The second test went really wrong for some reason and I couldn't get > all the information. > ----------- > Kernel General protection trap, eip 0x1051f9rotection trap, eip 0x107e92 > kernel: General protection (13), code=202 > Stopped at 0x1051f9: repe movsw (%esi),%es:(%edi) > db> trace > Bad character ']' > ? > db> show registers > Bad character ']' > ? > db> > --------- >
