Can I use DDB within splhigh()/splx() block?
Dear, I ran my system with modified 4.1R kernel, and I hit a problem. System is hanged, and I cannot even use ddb to break on the console. Is that possible kernel is trapped in splhigh()/splx() block? Thanks, -- -- Rex Luo Tel : 886-2-25521814 Ext. 824 Fax : 886-2-25521824 e-mail : [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
unpaired splbio() and splx() in vfs_unmountall()
Dear, I modifid kernel to write to disk directly after unmount all mounted filesystem in boot() kern/kern_shutdown.c. However, I found that my IO requests wouldn't have callback from device interrupt routine. I traced the codes and use gdb to find something out. The interesting is after execute vfs_unmountall() - dounmount() - ffs_unmount() - ffs_flushfiles() - vflush()- ??? the interrupt mask is set by splbio() without splx(), therefore, all my following requests cannot return. Notice that, the situation only happens after heavy IO, for example: cp 30 files at the same time. I use spl0() to solve the prolbem, but I think it's not the right way to do that. Can anyone provide some clues or suggestions. Thanks -- Rex Luo Tel : 886-2-25521814 Ext. 824 Fax : 886-2-25521824 e-mail : [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: unpaired splbio() and splx() in vfs_unmountall()
Dear Alfred, I have tried to add several asserts to verify its interrupt mask, however, the abnormal behaviour disappered if I did that. That's really rediculous and I don't know why? I would continue to find out what's the reason, and feedback if something new. Anyway, I really appreciate your help and kindness. Further question, what kind of books, or news, information I can get to study about pc's interrupt handling and architecture. Thanks, -- Rex Luo Alfred Perlstein [EMAIL PROTECTED] said: * Rex Luo [EMAIL PROTECTED] [010821 04:14] wrote: Dear, I modifid kernel to write to disk directly after unmount all mounted filesystem in boot() kern/kern_shutdown.c. However, I found that my IO requests wouldn't have callback from device interrupt routine. I traced the codes and use gdb to find something out. The interesting is after execute vfs_unmountall() - dounmount() - ffs_unmount() - ffs_flushfiles() - vflush()- ??? the interrupt mask is set by splbio() without splx(), therefore, all my following requests cannot return. Notice that, the situation only happens after heavy IO, for example: cp 30 files at the same time. I use spl0() to solve the prolbem, but I think it's not the right way to do that. Can anyone provide some clues or suggestions. That makes no sense. All you need to do is find the where the splbio() is that doesn't have a corresponding splx(). You can use the SPLASSERT functions to do that. -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? -- Rex Luo Tel : 886-2-25521814 Ext. 824 Fax : 886-2-25521824 e-mail : [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: qestion about vm page coloring
yes, I mean vm_page_t, and understand what you said. I will try to print the value of PQ_L2_SIZE in my kernel. Do you know what kernel options influence this value? I saw it is decided by PQ_CACHESIZE which is decided by different PQ_HUGE[LARGE/MEDIUM/...]CACHEsetting. Default setting PQ_CACHESIZE is 128, and corresponding PQ_L2_SIZE is 32. Am I right until now or something wrong? I use FreeBSD 4.1 release kernel to build my kernel. Anyway, thanks for your explaination. Rex Luo Matt Dillon [EMAIL PROTECTED] said: :Dear all, : : I study FreeBSD vm managememnt recently, however, I am a little confused :with vm_page's page color. when you call vm_add_new_page() in vm_startup(), :you will set each map entry's page color according to its physical addr. : : m-pc = (pa PAGE_SHIFT)PQ_L2_MASK; : :However, I found that almost each map entry's page color is zero, that means :PQ_L2_SIZE is 1, and disable page coloring option. Maybe I can do some :modification to dump PQ_L2_SIZE's value, but I think my guess is right. :Can someone please tell me the principle of page coloring, and why it's disabled :now? : :Thanks, : :Rex Luo I'm not sure what you mean by 'map entry'... vm_page_t's have color, and vm_object's have a base color to randomly offset the color of the vm_page_t's associated with the object, but vm_map_entry's do not have a page color associated with them. The page coloring works fine on my box, you may be looking at the wrong thing. PQ_L2_SIZE is definitely not 1 unless you've specified some weird kernel options in the kernel config. - Page coloring basically ensures that pages which are adjacent in virtual memory also wind up being adjacent in the L1 and L2 cpu caches in order to get more consistent cpu cache behavior. Without page coloring it is quite possible to have several adjacent pages in virtual memory wind up utilizing the same cpu cache page, which can effect performance with certain types of applications or certain cpu cache topologies. On IA32 pentium architectures the effect would probably not be all that noticeable, but getting consistent behavior is still a good thing. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
qestion about vm page coloring
Dear all, I study FreeBSD vm managememnt recently, however, I am a little confused with vm_page's page color. when you call vm_add_new_page() in vm_startup(), you will set each map entry's page color according to its physical addr. m-pc = (pa PAGE_SHIFT)PQ_L2_MASK; However, I found that almost each map entry's page color is zero, that means PQ_L2_SIZE is 1, and disable page coloring option. Maybe I can do some modification to dump PQ_L2_SIZE's value, but I think my guess is right. Can someone please tell me the principle of page coloring, and why it's disabled now? Thanks, Rex Luo To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
