July 2004 - Darwin-kernel - lists.apple.com

Re: debugging kernel paniced system
by Andrew Gallatin 27 Jul '04

27 Jul '04

Nikita Danilov writes: > Hmm.. seems osfmk/kern/debug.h contains more flags than mentioned in > KernelProgramming.pdf. I wonder what Yes, that's how I found out about the crashdumps ;) > #define DB_PANICLOG_DUMP 0x2000 /* Send paniclog on panic,not core*/ > I think it just transmits the actual panic string. It sends debug_buf, which is written to by the panic code. Drew _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

infinite loop in ffs_sync()
by Nikita Danilov 27 Jul '04

27 Jul '04

Hello, xnu/bsd/ufs/ffs/ffs_vfsops.c:ffs_sync() contains ---------------------------------------------------------------------- /* * Write back each (modified) inode. */ simple_lock(&mntvnode_slock); loop: for (vp = mp->mnt_vnodelist.lh_first; vp != NULL; vp = nvp) { int didhold = 0; /* * If the vnode that we are about to sync is no longer * associated with this mount point, start over. */ if (vp->v_mount != mp) goto loop; ---------------------------------------------------------------------- As mp->mnt_vnodelist is protected by mntvnode_slock lock, which is not released here, offending vnode cannot be removed from the list, and goto loop is infinite. Exactly the same bug was present in the ffs_vfsops.c:1.232 (Fri Apr 30 23:14:30 2004) version of this file in FreeBSD, but is fixed in FreeBSD HEAD. Nikita. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: debugging kernel paniced system
by Nikita Danilov 27 Jul '04

27 Jul '04

Andrew Gallatin writes: > Hello, Andrew, > Nikita Danilov writes: > > faster, emitting rather loud noise. It looks like CPU monitoring > > hardware is confused somehow (maybe thinks that CPU is in busy loop with > > interrupts off?), or just cannot work correctly without constant OS > > feedback. So, questions are: > > > > (a) is it possible to work around this, and > > I work around the noise by taking a dump of kernel memory to > another machine. This works remarkably like "crashdumps" on > tradidtional UNIX machines (ie, you don't need to keep the machine in > the crashed state, you can reboot and debug the crash later). Its > loud for a while, but usually its finished dumping before I could have > finished with a gdb session. > > You just need to have kdumpd running via inetd somewhere on your > network, and you need to have the appropriate boot args. > I use: > > boot-args -v debug=0xdae _panicd_ip=172.31.193.10 Hmm.. seems osfmk/kern/debug.h contains more flags than mentioned in KernelProgramming.pdf. I wonder what #define DB_PANICLOG_DUMP 0x2000 /* Send paniclog on panic,not core*/ means. Nikita. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: debugging kernel paniced system
by Nikita Danilov 27 Jul '04

27 Jul '04

Godfrey van der Linden writes: > G'day Nikita, Hello, Godfrey, > > The KDP protocol is transported using the ethernet driver that is > polling. This causes the CPU to spin really, really fast, (I'm not > sure what the other CPU is doing during this). So you are using 100% > of the CPU to keep up with the network, this needs to be cooled. > > Now when you start debugging you are deliberately setting the system up > to ONLY run your code in the driver being debugger. Unfortunately this > stops the fan controller driver from running. Thus the system > fails-safe by spinning up the fans until the driver start running > again. As you are using 100% CPU you probably do need to let the fans > go anyway. Yes, this makes perfect sense. > > You may be able to workaround the fans by breaking up your debugging > into sections. Instead of thinking at the GDB prompt, continue the > system then set another breakpoint after your have done your thinking. Back to the good old batch days. :) > > Finally as a general rule the system doesn't appreciate being unable to > run for too long, (I can't define 'too' long as it depends). > > Godfrey > Thank you for your help, Nikita. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

RE: Mac throws "Can't fork" after forking daemon a number of time s. W hats wrong ?
by Sanjay Mishra 27 Jul '04

27 Jul '04

Hi, I have some more information about the below mentioned problem. This does not occur on a single processor G5. On dual processor we don't have any problem either on G4 or G5. On single processor G4 we still have problems. I have run the ps -aux , top and Activity Monitor to watch the disk or memory activity. Everything looks fine. I do have enough space on my hard disk ( 2 GB empty space on hard disk, 1 GB RAM, 800 MHz processor, Panther (10.3) OS). The only difference is that with so much of RAM it goes up to 400 transactions. After that CUPS throws the error "Can't fork". Any Idea where to look in. The sample code of my cups Filter is as below. Assuming that my CUPS Filter calls pictwpstops the sample code inside my CUPS Filter is : if ((pid = fork()) == 0) { execlp("pictwpstops", printer, argv[1], argv[2], argv[3], argv[4], argv[5], argv[6], NULL); return (errno); } if (pid < 0) { return (-1); } // Now wait for the filter to complete... if (wait(&status) < 0) { return (-1); } Thanks, Sanjay Mishra -----Original Message----- From: darwin-kernel-admin(a)lists.apple.com [mailto:darwin-kernel-admin@lists.apple.com]On Behalf Of Sanjay Mishra Sent: Wednesday, July 07, 2004 4:09 PM To: darwin-kernel(a)lists.apple.com Subject: Mac throws "Can't fork" after forking daemon a number of times. W hats wrong ? Hi, I have written a CUPS filter on Mac (Panther) and it is working fine on dual processor machines but on single processor Mac the OS throws an error "Can't fork" after around 80 transactions. Only when I am using my filter this message is thrown.I am not doing much in my filter.I just pass all the arguments to it to one of the existing filters using execlp() and call wait() as the last function in the filter. My application has many parts. One of them process the HTTP request. The other is the CUPS filter. The third which converts the document requested in the PDF format. Hence the sequence is that when the application receives the HTTP request for sending a file across it gets the file from a predefined location and converts it into PDF format (during this the CUPS filter gets called by the OS) and is sent across the network to the client. After around 80 transactions and that too only on the single processor Mac machines it throws the error "can't fork". What could be going wrong? Where I should start looking into ? I looked at the number of files my application opens and it is closing all of them at the proper place. Are there any tool that can help me out. Where ever I am forking I made sure that it does not hang and closes properly. I tested them.No error is thrown if I am running the application on dual processor system. Regards, Sanjay Mishra _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

NKE - DLIL network interfaces filter
by Guy Meyer 26 Jul '04

26 Jul '04

Hi I am interested in writing an NKE which will attach to every network interface using "dlil_attach_interface_filter" . In order to attach to the interface I am planing on listing to the dlil_event. How can I be sure that between the time I received the event that the interface was attached and the time I have set up the interface filter, an input/output data frame had not been communicated through the interface without passing through the filter. I know that with linux you can setup a bpf filter that will catchup all interfaces, AFAIK this is not possible on darwin. Thanks Guy _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: debugging kernel paniced system
by Andrew Gallatin 26 Jul '04

26 Jul '04

Nikita Danilov writes: > faster, emitting rather loud noise. It looks like CPU monitoring > hardware is confused somehow (maybe thinks that CPU is in busy loop with > interrupts off?), or just cannot work correctly without constant OS > feedback. So, questions are: > > (a) is it possible to work around this, and I work around the noise by taking a dump of kernel memory to another machine. This works remarkably like "crashdumps" on tradidtional UNIX machines (ie, you don't need to keep the machine in the crashed state, you can reboot and debug the crash later). Its loud for a while, but usually its finished dumping before I could have finished with a gdb session. You just need to have kdumpd running via inetd somewhere on your network, and you need to have the appropriate boot args. I use: boot-args -v debug=0xdae _panicd_ip=172.31.193.10 This causes dumps to go to 172.31.193.10 (my FreeBSD server, running kdumpd out of inetd). It also causes a dump to be taken when I press the power button (rather than sleeping the computer). The FreeBSD inetd.conf entry looks like the following (a new-fangled MacOSX inetd.conf entry would look different). kdumpd dgram udp wait root /usr/libexec/kdumpd kdumpd -l -u gallatin -s /home/gallatin/macdump I also needed to add this line to /etc/services on the FreeBSD machine: kdumpd 1069/udp I end up with cores (with names like core-xnu-517-172.31.193.9-1a8f2e15) written to /home/gallatin/macdump. After that, you run gdb mach_kernel core-xnu-517-172.31.193.9-1a8f2e15 Drew _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: debugging kernel paniced system
by Godfrey van der Linden 26 Jul '04

26 Jul '04

G'day Nikita, The KDP protocol is transported using the ethernet driver that is polling. This causes the CPU to spin really, really fast, (I'm not sure what the other CPU is doing during this). So you are using 100% of the CPU to keep up with the network, this needs to be cooled. Now when you start debugging you are deliberately setting the system up to ONLY run your code in the driver being debugger. Unfortunately this stops the fan controller driver from running. Thus the system fails-safe by spinning up the fans until the driver start running again. As you are using 100% CPU you probably do need to let the fans go anyway. You may be able to workaround the fans by breaking up your debugging into sections. Instead of thinking at the GDB prompt, continue the system then set another breakpoint after your have done your thinking. Finally as a general rule the system doesn't appreciate being unable to run for too long, (I can't define 'too' long as it depends). Godfrey On Jul 25, , at 0:30, Nikita Danilov wrote: By the way, I have related question. When kernel is under debugger control for enough time (for example, when I single-step through kernel code, or just inspect kernel data), fans start rotating faster and faster, emitting rather loud noise. It looks like CPU monitoring hardware is confused somehow (maybe thinks that CPU is in busy loop with interrupts off?), or just cannot work correctly without constant OS feedback. So, questions are: (a) is it possible to work around this, and (b) is it dangerous (like, can it ultimately damage fans)? _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: How to get CPU cycles per sec?
by Jonas Maebe 26 Jul '04

26 Jul '04

On 26 jul 2004, at 01:21, Jay A. Kreibich wrote: Sorry, I should have been more specific. When I said "always" I meant that regardless of the energy saver settings, it always returns the same value. I've played with this quite a bit trying to figure it out, since the energy saver settings were also my first guess as to why the number didn't seem to make sense. Afaik this is a somewhat known problem (specific to the 800MHz TiBooks). I've read about this oddity before anyway, though I don't remember where (xlr8yourmac or macintouch probably). But you can rest assured that your machine really is running at 800MHhz :) Jonas _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: debugging kernel paniced system
by Shawn Erickson 26 Jul '04

26 Jul '04

On Jul 25, 2004, at 6:34 PM, Shawn Erickson wrote: On Jul 25, 2004, at 5:57 PM, Matt Jaffa wrote: Hi, I have successfully tracked down how to repeat my KEXT causing kernel panics, and I have successfully connected to it remotely to debug, but once I am connected and attached to the remote machine, what must I type/do to figure where in the code was the problem? Not sure someone can help you much via the medium of email, it is a big complex subject... I suggest reviewing what documentation you can find on GDB and any example of using it. Have you looked over the following that Apple provides...? <http://developer.apple.com/documentation/Darwin/Conceptual/ KernelProgramming/build/chapter_18_section_5.html> <http://developer.apple.com/technotes/tn2002/tn2063.html> Oops... I meant to point out the use of the "trace" command in GDB is likely the first step if you have it trapped during a panic in the debugger. If you have symbols for your KEXTs loaded it should quickly point you to the location of the issue. Additionally you can down load the symbols for the kernel you are running [1] to be able to better understand the Apple half of the equation. Also the Apple folks have a set of GDB macros to help debug IOKit, etc. however I cannot recall how to get them at the moment. -Shawn [1] <http://developer.apple.com/sdk/> look for "Kernel Debug Kit" on that page and download the one that matches the OS you have installed. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0