New 13" MacBook Air 2 Kernel Panics in 2 Hours

Just an update.

The disabling of IPv6 didnt resolve the crash issue when on DTU's network. It happens a lot less frequent but it still happens.

So my 100% working workaround is to use my bootcamp windows 7 when I am at DTU which is stable as a rock.

This was not really what i paid for....

I have the same problem using Eduroam at DTU's network, although IPv6 is disabled. It kernel panics many times per day...

panic(cpu 3 caller 0xffffff80003456b1): "Failed mbuf validity check: mbuf 0xffffff807ae68c00 len -2 " "type 1 flags 0x3 data 0xffffff807aecf000 rcvif en1 ifflags 0x8863"@/SourceCache/xnu/xnu-1699.24.8/bsd/net/dlil.c:1484

Backtrace (CPU 3), Frame : Return Address

0xffffff807f623e40 : 0xffffff8000220702

0xffffff807f623ec0 : 0xffffff80003456b1

0xffffff807f623f60 : 0xffffff8000340e79

0xffffff807f623fb0 : 0xffffff8000820057

BSD process name corresponding to current thread: kernel_task

Mac OS version:

11C74

Kernel version:

Darwin Kernel Version 11.2.0: Tue Aug 9 20:54:00 PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64

Kernel UUID: 59275DFA-10C0-30B3-9E26-F7B5DFB1A432

System model name: MacBookPro8,1 (Mac-94245B3640C91C81)

We still have the same problems... Just saw two Macbook kernel panic at the same time!

panic(cpu 3 caller 0xffffff80003456b1): "Failed mbuf validity check: mbuf 0xffffff807ae68c00 len -2 " "type 1 flags 0x3 data 0xffffff807aecf000 rcvif en1 ifflags 0x8863"@/SourceCache/xnu/xnu-1699.24.8/bsd/net/dlil.c:1484

Fix?

I had the same kernel panic just now being on wireless network at The Technical University of Denmark (But not on the eduroam network).

Sat Nov 26 16:50:53 2011

panic(cpu 0 caller 0xffffff80003456b1): "Failed mbuf validity check: mbuf 0xffffff803bafcc00 len -2 " "type 1 flags 0x3 data 0xffffff803bb44000 rcvif en1 ifflags 0x8863"@/SourceCache/xnu/xnu-1699.24.8/bsd/net/dlil.c:1484

Backtrace (CPU 0), Frame : Return Address

0xffffff803ff53e40 : 0xffffff8000220702

0xffffff803ff53ec0 : 0xffffff80003456b1

0xffffff803ff53f60 : 0xffffff8000340e79

0xffffff803ff53fb0 : 0xffffff8000820057

BSD process name corresponding to current thread: kernel_task

Mac OS version:

11C74

Kernel version:

Darwin Kernel Version 11.2.0: Tue Aug 9 20:54:00 PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64

Kernel UUID: 59275DFA-10C0-30B3-9E26-F7B5DFB1A432

System model name: MacBook5,1 (Mac-F42D89A9)

I have the problem here when using wi-fi and the Airport driver. The suspicious driver is shown in panic reports as:

com.apple.driver.AirPort.Atheros40(501.58.1)

which I assume is the driver for the Wi-Fi hardware system. The problem occurrs only when using FaceTime on this iMac here running Lion, and is solved if I hard-wire the network via the Ethernet port rather than using the wi-fi system. This is consistent with reports in this thread. Not all access points are created equal, and some have more trouble with data corruption and retries than others, so speeds vary. My guess is that any any attempted transfer of data through a network interface of any sort which exceeds the capaciy of the interface will cause this problem. This will, of course, be seen mostly with a wi-fi connection, and with programs (such as FaceTime) which require substantial bandwidth. The behavior will almost certainly vary from AP to AP, as noted by several posters here.

My guess is that this is a buffer or queue overrun issue, although I could easily be wrong 😉 All the reports I've seen indicate that this is a software, not a hardware issue.

I called up Mac tech support and ended up talking to a senior tech person, who told me that FaceTime required a lot of bandwith (duh!!), and that I'd exceeded the capabilities of the device, or the access point, and that that's why the kernel panics were occurring. I explained to him that if a driver or any other system software component is stressed, or has it's operating limits exceeded, it should at least shut down gracefully and reload itself, and that a kernel panic is pretty much to opposite of a "graceful exit", and that quality software, on which I believe Apple prides itself, handles exceptional conditions without amplifying these conditions back into the OS core. I don't know how far up the ladder this particular piece of sysadmin wisdom will make it. This ain't like Ubuntu or Gentoo Linux where I can post a bug report on Launchpad or Bugzilla and actually maybe have a chance to interact with the developers to some degree.

So people who are having this problem need to do what they can to make noise with Apple about it. The squeaky wheel gets the oil.

I have the exact same problem, also at DTU with a Macbook Air 13". The problem seems to be more frequent when many laptops are using the same router, since I was able to use the wifi for many hours without problems during saturday and sunday.

Same problem here at DTU library, but I have a Macbook 13'' (not Air) with Lion.. it crashed 6 times in 3 days..

This makes good sense since mDNSResponder is using alot of bandwidth to "talk" to other Macs. I think this is where the overload happens at some point making the driver crash.

This seems to be a general problem with DTU wireless network and Lion computers. Since the DTU network havent changed it is some bug with Lion. An official response would be nice since numerous people are affected by the exact same error.

Hi all.

I have had the same issues with kernel panics (also at DTU) once or twise a day, but since i formatted my entire mac partition and reinstalled Lion – with no use of Time Machine – I have not had any panics (It has been working for one week so far). I guess (at least for me) that the problem is releated to the way Lion is installed on top of Snow Leopard, since a clean install of Lion seems to work.

Hopefully it permanently solves this huge problem if an opdate couldn't. I will return if the panics occurs again.

I also reinstalled Lion, and since that, I have not experienced any crashes. But I bought my MacBook Air with Lion installed as default, so I think the problem was with the first versions of Lion.

Ok, the workaround didn't work!!! Got a Kernel Panic at DTU again today. I hate Lion – Snow Leopard works 1,000 times better. I'll use a network cable at DTU in the future.

I hope this will be fixed ASAP, Apple!