On Thu, 27 Mar 2008, Rafael J. Wysocki wrote:Fixed by 4cde32fc4b32e96a99063af3183acdfd54c563f0, methinks. Needs more info. The original oops that opened it is fixed, but.. This one seems gone (and was apparently AVR-only): http://lkml.org/lkml/2008/2/13/607: "What ever the problem is it isn't immediately apparent in latest git so I guess we'll just have to keep our eyes peeled." Hmm. It is a regression on one machine (2x quad-core stoakley), but not another (4x quad-core tigerton). Interestingly, the stoakley box numbers have apparently been all over the map. Andrew and seems to have debugged this down to a kzalloc(GFP_ATOMIC) or similar. I wonder if the bug is in that commit 3811dbf67162bd08412f1b0e02e554f353e93bdb ("SLUB: remove useless masking of GFP_ZERO"), because I don't think that masking was at all useless and I think my original 7fd272550bd43cc1d7289ef0ab2fa50de137e767 was correct. That apparently bogus commit says "GFP_ZERO is already masked out in new_slab()", but gfpflags is not just used for new_slab(), but for kmalloc_large() too. Which does *not* clear GFP_ZERO. Pawel, does reverting 3811dbf67162bd08412f1b0e02e554f353e93bdb fix it for you? Also, Rafael - do these reminder emails also go to the people who are mentioned in the regressions (especially people who are set up as being "hanled-by" or having patches for the problem)? Linus --
| Greg Kroah-Hartman | [PATCH 002/196] Chinese: rephrase English introduction in HOWTO |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Roland Dreier | Re: Integration of SCST in the mainstream Linux kernel |
git: | |
| Radu Rendec | htb parallelism on multi-core platforms |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
