* Russell King - ARM Linux <li...@arm.linux.org.uk> [150316 09:15]: > On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren wrote: > > * Pavel Machek <pa...@ucw.cz> [150302 03:32]: > > > On Fri 2015-02-27 16:55:26, Pali Rohár wrote: > > > > This patch adds support for DT "/revision" and convert ATAG_REVISION to > > > > DT. > > > > > > > > Pali Rohár (2): > > > > arm: devtree: Set system_rev from DT revision > > > > arm: boot: convert ATAG_REVISION to DT revision field > > > > > > Acked-by: Pavel Machek <pa...@ucw.cz> > > > > Are these queued somewhere now? Sounds like this is the last pending > > issue for n900 to use legacy user space with current mainline kernels, > > so I'd like to get these in so we can get closer to making omap3 boot > > in device tree only mode. > > Not that I know of. As everyone is aware, patches need to be in my > patch system if they want me to apply them - which would've been > especially important as I was away from kernel stuff for a week at > the start of March (for medical reasons) and I can't be expected to > track the status of stuff which is buried behind 1000+ extra mails.
Pali, care to upload these two patches to Russell's patch tracking system if no other comments? > In any case, I'm currently not accepting /any/ patches into my tree at > present; I'm chasing a horrid instability on one of my test platforms > which is making it impossible to tell whether any particular change or > changes in my tree is responsible or not for it. It doesn't seem to be > a hardware failure (if it was, I'd simply take the board out of the > nightly test system.) > > It's quite literally taking hours to figure out what's going on - I've > been on this for about 12 hours now and still not much closer to knowing > what's causing it (other than I know that -rc1 plus my queue seems to be > fine, -rc3 plus my queue is definitely broken, -rc3 alone is fine. So > something I'm already carrying seems to be responsible, but each time I > identify a particular patch and drop _just_ that change, I find that the > problem is back when I try my queue minus the bad changes. With a test > cycle time of 20+ minutes (due to the number of boots required to make > certain of a dependable result), this is /really/ slow progress. > > Right now, I can't be positively sure that /anything/ I have already > merged isn't a factor in causing this problem, so I don't want to > augment my tree with any additional patches which would upset my > ability to move about in the tree, and get reproducable results from > repeated testing. To merge something else will probably mean I'll > have to start again from the beginning and the last 12 hours spent > testing will have been wasted. Oh debugging those things sucks. Maybe try with CONFIG_DEBUG_SLAB to see if you trigger any poison. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/