kernel panic on mac os x

[fokke]

I've had a few kernel panics on 10.3 and I suspect that it has something to do with the IOWarrior40. Here's the panic log:

Tue Jul 19 02:26:45 2005


panic(cpu 0): zalloc
Latest stack backtrace for cpu 0:
Backtrace:
0x00083878 0x00083D5C 0x0001EDA4 0x00039038 0x000241A0 0x000131F0 0x00013918 0x000219E8
0x0027DB20 0x00253A7C 0x00253BB0 0x00255C30 0x0052E760 0x00280414 0x0007B638 0x00021668
0x0001BCE8 0x0001C0F0 0x00094538 0x49228100
Kernel loadable modules in backtrace (with dependencies):
com.apple.iokit.IOHIDFamily(1.3.6)@0x52d000
Proceeding back via exception chain:
Exception state (sv=0x2BDBD500)
PC=0x900074C8; MSR=0x0000D030; DAR=0x065E5FFC; DSISR=0x42000000; LR=0x90007018; R1=0xF02849B0; XCP=0x00000030 (0xC00 - System call)

Kernel version:
Darwin Kernel Version 7.7.2:
Wed Dec 22 20:01:20 PST 2004; root:xnu/xnu-517.10.7.obj~1/RELEASE_PPC

any idea's on how to solve this would be very welcome.

[Guido Körber]

Which revision of 10.3?

The interesting thing here is that we do not install any kernal modules. So this comes from the standard Apple driver.

[fokke]

this is on 10.3.7. And it doesn happen right away, but after a while ,having done a lot of calls to IOWarriorWriteInterface0() and IOWarriorReadInterface0(). It seems to be rather unpredictable when it happens.

[Guido Körber]

Can you upgrade to 10.3.9? AFAIK the HID drivers have been revised for .9.

[fokke]

I'll give it a try and see if it helps.

[fokke]

one more thing, i'm doing 50 reads and writes every second. Could this be too much?

[Guido Körber]

No, this should be fine.

[Erik]

Shoot. Looks like I just got a similar panic too, also in IOKit. I will see if I can submit this to Apple, since the crash is in their code. This is in OS X 10.3.9.

I was doing fast access as well. It made it all afternoon yesterday, and for a period today before happening, so it seems to be intermittent for me too.

I really want to do input via "interrupt" so as to avoid all this polling anyway. Hopefully I can figure that out (please see related topic in this forum if you can help me with interrupts). I will try slowing things down and perhaps using Mac OS 10.4 to see if anything is different. Here's my panic log

Code: Select all

Wed Aug 24 12:46:21 2005


panic(cpu 0): zalloc
Latest stack backtrace for cpu 0:
      Backtrace:
         0x00083498 0x0008397C 0x0001EDA4 0x00038C48 0x000241A0 0x000131F0 0x00013918 0x000219E8 
         0x0027E0E0 0x0025403C 0x00254170 0x0025607C 0x007E06BC 0x002809D4 0x0007B09C 0x00021668 
         0x0001BCE8 0x0001C0F0 0x00094318 0x002F006B 
      Kernel loadable modules in backtrace (with dependencies):
         com.apple.iokit.IOHIDFamily(1.3.6)@0x7df000
Proceeding back via exception chain:
   Exception state (sv=0x2DA25C80)
      PC=0x90007878; MSR=0x0000D030; DAR=0x11E5A000; DSISR=0x42000000; LR=0x900073F8; R1=0xBFFFF990; XCP=0x00000030 (0xC00 - System call)

Kernel version:
Darwin Kernel Version 7.9.0:
Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC

[Erik]

So far, this seems like a resource depletion problem. I've done some brief tests and found that I can make the kernel panic happen somewhat predictably. My polling interval is not precise, it's just sleeping for that duration in between checks, not using a real time clock, but the pattern is evident regardless of the lack of accuracy:

Code: Select all

Polling Inverval --  Duration 'til panic
          2 ms   --    0.5 hrs
          5 ms   --    1.1 hrs
         10 ms   --    1.6 hrs
         25 ms   --    3.3 hrs

The time until crash is inversly proportional to the rate of polling so it's like there's some resource being depleted (it gets roughly half a million reads in before crashing). Perhaps something is not being free'd that needs to be???

True, a simple resource depletion should be detected and handled properly and never legitimately result in a kernel panic (what should anyway) but perhaps there is something that can be done about it in the IO Warrior library? I am not an expert on USB stuff but I'll look and see if I can spot anything fishy!

Right now, I've been running at 2ms polling time, but quitting and relaunching the application every 20 minutes or so (before the half hour panic time)! No crash yet, so this may be a workaround. Next step will be to make the app release the device periodically (rather than actually quitting) and see if that has similar success. If so, I'll just go to a slower polling rate and periodically release and reacquire the device (I don't actually need 500 samples per second!). Unfortunate workaround, but at least it appears to help and is preferred to a kernel panic!

I might end up trying to write a "kext" anyway, to get around my difficulty with "interrupts" and hopefully with this kernel panic too. Should be fun!

[fokke]

i think i've found a possible fix/woraround. In IOWarriorLib.c in IOWarriorWriteToInterface() and IOWarriorReadFromInterface() the device is opened and closed every time. I removed te open/close calls from these functions and open/close only once rather then every read/write. This seems to have solved the problem. I don't know whether this will cause other problems but it looks like everything is working now.

[wler]

Hi,

I run into the same problem, even with OSX 10.4.6 - kernel panic after reading data for a certain amount of time. Did this workaround work for you since then without other problems? Would you mind sending the modified IOWarriorLib.c ?

Thanks!
-WL

[fokke]

yes, this has worked for me since. Rather than modify IOWarriorLib.c, i created these alternatives to IOWarriorWriteToInterface() and IOWarriorReadFromInterface().
just call openInterface0() once and then use readfromIOW or writetoIOW subsequently.

void openInterface0()
{
IOReturn ioReturnValue = kIOReturnSuccess;
IOWarriorHIDDeviceInterface** interface = IOWarriorFirstInterfaceOfType (kIOWarrior40Interface0);
ioReturnValue = (*interface)->open (interface, 0);
if (ioReturnValue != kIOReturnSuccess)
{
// PrintErrMsgIfIOErr (ioReturnValue, "Could not open hid device interface");
throw std::runtime_error("Could not open hid device interface");
//return ioReturnValue;
}
}

void closeInterface0()
{
IOWarriorHIDDeviceInterface** interface = IOWarriorFirstInterfaceOfType (kIOWarrior40Interface0);
(*interface)->close (interface);
}

int readfromIOW(void* outData)
{
IOWarriorHIDDeviceInterface** inInterface=IOWarriorFirstInterfaceOfType (kIOWarrior40Interface0);;
IOReturn ioReturnValue = kIOReturnSuccess;

UInt32 dataSize = 4;
ioReturnValue = (*inInterface)->getReport (inInterface, kIOHIDReportTypeInput,
0, outData, &dataSize, 50, NULL, NULL, NULL);
if (ioReturnValue != kIOReturnSuccess)
{
throw std::runtime_error("Could not write setReport on hid device interface");

return ioReturnValue;
}
return ioReturnValue;

}

int writetoIOW(void* inData)
{

IOWarriorHIDDeviceInterface** interface=IOWarriorFirstInterfaceOfType (kIOWarrior40Interface0);;
IOReturn ioReturnValue = kIOReturnSuccess;
UInt32 dataSize = 4;
if (interface)
{
ioReturnValue = IOWarriorWriteToInterface (interface, dataSize, inData);
}
else
return -1;

return ioReturnValue;

}

[wler]

Thanks for the prompt reply!
That's gonna save me a bit of work.

All the best,
WL