Apple Event: May 7th at 7 am PT

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Logitech, Snow Leopard. and kernel panics: who's the culprit?

Up until this morning, I'd been considering this a Logitech issue, but their tech support just emailed me blaming Apple, so I'm posting it here.

With versions 3.1, 3.2, and now 3.3 of the Logitech Control Center (driver software for mice and keyboards), I've consistently seen kernel panics fly by my verbose login, always at odds with iokit:

6/26/10 7:24:43 PM kernel dependency: com.apple.iokit.IOUSBFamily(4.0.2)@0x8623d000
6/26/10 7:24:43 PM kernel dependency: com.apple.iokit.IOHIDFamily(1.6.4)@0x85ff6000
6/26/10 7:24:43 PM kernel dependency: com.apple.iokit.IOUSBHIDDriver(4.0.2)@0x86865000

The computer always finishes starting up, and it doesn't appear to crash anything after it does so. That makes it more of a curiosity than a crisis, I suppose, but at the same time, no kernel panic is a good kernel panic, right? It has to be compromising the system in some way, so I'd like to get to the bottom of it.

I like Logitech products, so my theory was that the release of Snow Leopard a couple years ago had simply caught them off guard, and that they might need version or two to get their software to play nicely with 10.4. But the recently released 3.3 of the LCC generates the exact same panics.

So I emailed Logitech support. A charmingly named "Ms. Valentine" quickly responded, but embedded in form language, she told me to "Please contact you computer manufacturer, because this is Internal Fatal Error."

So 1) is this in fact an Apple problem, or the passing of a buck? and 2) whoever's to blame, is this kernel panic anything to worry about?

Thanks in advance for your thoughts and theories.

2x3GHz Dual-Core Intel Xeon, Mac OS X (10.6.4)

Posted on Jun 27, 2010 1:47 PM

Reply
11 replies

Jun 27, 2010 2:19 PM in response to MattGiraud

Perhaps I should add some more detail. If you verbose login, the startup process is detailed in code on your screen. In this case, so many "backtrace (with dependencies)" cycles are detailed that they do indeed fly by. The full detail of each cycle:

6/27/10 12:59:52 PM kernel Trying to change a collection in the registry
6/27/10 12:59:52 PM kernel Backtrace 0x4ff608 0x4ff3aa 0xa0269d 0x9f803a 0xa023ef 0xa023ac 0xa02e01
6/27/10 12:59:52 PM kernel Kernel Extensions in backtrace (with dependencies):
6/27/10 12:59:52 PM kernel com.Logitech.Control Center.HID Driver(3.3.0)@0x9e9000->0xa13fff
6/27/10 12:59:52 PM kernel dependency: com.apple.iokit.IOUSBFamily(4.0.2)@0x976000
6/27/10 12:59:52 PM kernel dependency: com.apple.iokit.IOHIDFamily(1.6.4)@0x9a7000
6/27/10 12:59:52 PM kernel dependency: com.apple.iokit.IOUSBHIDDriver(4.0.2)@0x9e3000

Most of the folks I've read discussing this issue have called this a kernel panic, but maybe they're using the term loosely.

In any case, the question remains: is this persistent issue an OSX one, or a Logitech one; and either way, is it compromising anything?

Jun 27, 2010 2:47 PM in response to Barney-15E

Thanks, macjack. It's true that once I uninstall it, the kernel issues disappear. But the software ( http://www.logitech.com/en-us/494/3129) does add significant functionality to the mouse and keyboard, so it'd be a shame to lose it.

Thanks also, Barney. Whatever it's called, Logitech support staff characterize it as an "Internal Fatal Error" (as you saw in their response above), so at least as far as they're concerned, it's not benign.

So can a "dependency" be safely ignored, or does it indicate a problem that really should be solved?

Jun 27, 2010 2:59 PM in response to MattGiraud

Thanks also, Barney. Whatever it's called, Logitech support staff characterize it as an "Internal Fatal Error" (as you saw in their response above), so at least as far as they're concerned, it's not benign.


So can a "dependency" be safely ignored, or does it indicate a problem that really should be solved?

Dependencies are normal. They are hooks into the kernel extensions that make it possible to use the hardware in the system.

What you may be confusing this with is when a kernel panic occurs, it reports the dependencies in the backtrace so that you can try to determine what is causing the kernel panic. If you told Ms. Valentine that you are having kernel panics and that is what is showing up in the backtrace, then she is going to assume you are actually getting a kernel panic. Also, in reading her script, she will initially put any blame on Apple, hoping you will just go away. However, if a company writes a driver that attaches itself to kernel extensions, it is solely their responsibility to make sure it works.

Jun 27, 2010 3:36 PM in response to MattGiraud

I've had nothing but trouble with Logitech's drivers on both Mac and Windows over many years. They make great hardware, but they simply do not write good drivers and never have. (As you've discovered, their support is also worthless.) I tried LCC for about a week on my first MacBook Pro and it crashed and hesitated constantly. I got rid of it, installed Steermouse (Google it) and everything has been just fine ever since. Steermouse has all the functionality of LCC and is rock solid.

Jun 27, 2010 5:02 PM in response to danegeld

Thanks much, everyone - and especially danegeld. To sum up the answers to my initial questions:

- this is almost certainly a Logitech software problem, and one they've therefore neglected to address for at least 3 versions.

- the errors I detailed above are not panics, but "dependencies"

- those dependencies aren't the cause for concern panics are, but to avoid them completely, try another piece of software -- like Steermouse, which I've just downloaded and installed (it's here: http://www.apple.com/downloads/macosx/drivers/steermouse.html ). The result so far has been backtrace-free and smooth sailing so far.

Logitech, Snow Leopard. and kernel panics: who's the culprit?

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.