After looking at this some more, my bisect has left me between these two
commits:
The last good commit:
[db9d8c60266a5010e905829e10cd722519e14777] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
The last bad commit:
[45e7715922217493f01c8238d8c9eff5c3fea5a2] Merge tag
'pinctrl-for-v3.7-late' of
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Both of these show up as 3.6.0-rc6 kernels
Bisecting these leaves me at:
[70418e6efcf4f8652cc08e3f2ab8ae35f0948fd9] NFC: pn533: Fix mem leak in
pn533_in_dep_link_up
This leaves me with a 3.6.0-rc1 kernel (according to the root Makefile)
that behaves far differently than the two first commits listed above. I
don't have much confidence in using the bisect since things that worked
before (like X Windows) don't work, and there's all these 'tty_init_dev:
XX callbacks suppressed' messages that weren't there before.
So I pulled each individual patch between the last good and last bad
commit and started applying them individually. It looks like commit
'38c1a01cf10c6e4049b4ffbd4a6af655df2a46e1 wireless: add back sysfs
directory' is the one that fixes things.
After applying this patch, the machine will run for days without
incident. Reverting the patch lets the failure appear in under 1 hour.
Now looking at the Wheezy 3.2.x kernel, the code from that patch is
already included, but some of the code is hidden behind
CONFIG_WIRELESS_EXT_SYSFS and Wheezy's config file has '#
CONFIG_WIRELESS_EXT_SYSFS is not set' where my working 3.7.x kernel has
the equivalent setting ('CONFIG_CFG80211') enabled to pull in the code.
Flipping the Wheezy config to 'y' and rebuilding has allowed the machine
to run the Wheezy 3.2.39 kernel for a full day without incident.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
