From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: Kernel panic, reboot in 5 seconds Date: Thu, 21 May 2015 16:17:15 +0200 Message-ID: <1432217835.7907.98.camel@citrix.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8040786091642061355==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Mr Idris Cc: George Dunlap , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org --===============8040786091642061355== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Sj6UO/OFlsSSlKNSdC4N" --=-Sj6UO/OFlsSSlKNSdC4N Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2015-05-21 at 15:06 +0200, Mr Idris wrote: > On 5/18/15, George Dunlap wrote: > >> (XEN) Xen call trace: > >> (XEN) [] schedule+0x408/0x5df > >> (XEN) [] __do_softirq+0x81/0x8c > >> (XEN) [] do_softirq+0x13/0x15 > >> (XEN) [] idle_loop+0x64/0x74 > >> (XEN) > >> (XEN) Pagetable walk from 00000000000000c8: > >> (XEN) L4[0x000] =3D 0000000215507063 ffffffffffffffff > >> (XEN) L3[0x000] =3D 0000000215506063 ffffffffffffffff > >> (XEN) L2[0x000] =3D 0000000215505063 ffffffffffffffff > >> (XEN) L1[0x000] =3D 0000000000000000 ffffffffffffffff > >> (XEN) > >> (XEN) **************************************** > >> (XEN) Panic on CPU 0: > >> (XEN) FATAL PAGE FAULT > >> (XEN) [error_code=3D0000] > >> (XEN) Faulting linear address: 00000000000000c8 > >> (XEN) **************************************** > >> (XEN) > >> (XEN) Reboot in five seconds... > >> (XEN) Debugging connection not set up. > > > > Fundamentally, the bug you're getting is that you're dereferencing a > > null pointer, probably into a struct (that's the "Faulting linear > > address" -- 0xc8 will be the offset into the struct). > Thanks for the information. >=20 > I'm still confuse with the do_schedule() on each scheduler in xen. > There are 2 parameters that i think the most important to build simple > scheduler, ret.time and ret.task. > ret.migrated as well, as per: struct task_slice { struct vcpu *task; s_time_t time; bool_t migrated; }; in xen/include/xen/sched-if.h. It's important for decidine whether we need to call sched_move_irqs(). > ret.time is the time that is set for the VCPU, anyVCPU which run. > I can't parse this sentence (or, at least, I can't be sure I'm parsing it right). ret.time is the next time instant you want a timer to fire, as you can see right below the call do sched->do_schedule(), in schedule.c. That timer, when firing, will cause the scheduler to run again, as it also can be easily seen in schedule.c, checking out occurrences of s_timer and s_timer_fn. > ret.task is the context or domain that should be run/scheduled. Am i corr= ect? > It's the vcpu to be run next, yes. > Or where can i set which domain/process/context should run first? >=20 I'm not sure I'm getting this either... IIUIC, that is what you should do in your implementation of the do_schedule hook, for your scheduler. I mean, Credit does it in csched_schedule(), Credit2 in csched2_schedule(), RTDS in rt_schedule(), ARINC653 in a653sched_do_schedule(). But maybe I'm missing what you mean with "should run *first*". BTW, what's the purpose of the new scheduler you're working on, if I can ask? Regards, Dario --=-Sj6UO/OFlsSSlKNSdC4N Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlVd6OsACgkQk4XaBE3IOsQw9gCdEtPyP4S7QlUO56FCifHIDM9r BoAAnRO3HZUUkwLxroLsZz2JXUQdqyQg =SBgp -----END PGP SIGNATURE----- --=-Sj6UO/OFlsSSlKNSdC4N-- --===============8040786091642061355== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8040786091642061355==--