* James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 2009-03-03 at 20:22 +0100, Ingo Molnar wrote: > > * James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > On Tue, 2009-03-03 at 17:08 +0100, Jan Engelhardt wrote: > > > > On Tuesday 2009-03-03 16:21, James Bottomley wrote: > > > > >> > $ slabtop > > > > >> > OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME > > > > >> > 818616 818616 100% 0.16K 34109 24 136436K sgpool-8 > > > > >> > 253692 253692 100% 0.62K 42282 6 169128K sgpool-32 > > > > >> > 52017 52016 99% 2.50K 17339 3 138712K sgpool-128 > > > > >> > 26220 26219 99% 0.31K 2185 12 8740K sgpool-16 > > > > >> > 8927 8574 96% 0.03K 79 113 316K size-32 > > > > >> > > > > >> Looks like a leak, by failing to call scsi_release_buffers() > > > > >> somehow. (Which was changed recently) > > > > > > > > > >Firstly, I have to say I don't see this in the mainline tree, so could > > > > >you try that with your setup just to verify (git head at 2.6.29-rc6). > > > > > > > > Yes, looking at the rt patch (in broken-out it's in origin.diff), > > > > it seems a bit obvious - the scsi_release_buffers is not called anymore: > > > > > > OK, this is a bad patch, so just revert it. It was posted to > > > linux-scsi initially in this form before the author posted a > > > new one with the missing release buffers added. It looks like > > > the first incarnation got pulled into the -rt tree for some > > > reasons. > > > > Uhm. I applied a test-patch from Alan Stern, to possibly fix an > > SCSI lockup with aic7xxx that _I_ reported to you and then to > > the scsi-list. > > > > You were Cc:-ed to that test patch and to my bugreport as well, > > all the way. Do you claim that you dont remember it? > > ? If I've just quoted the patch above why would I not remember it now. > I've just said it's the cause of the problems in the -rt tree. > > > The saga is still documented in tip:out-of-tree (which is a > > special branch with out-of-tree hotfixes): > > > > 7e4cbd1: fix "scsi: aic7xxx hang since v2.6.28-rc1" > > e027abc: scsi: temporarily undo scsi reverts > > 813104e: Revert "[SCSI] simplify scsi_io_completion()" > > 84db545: Revert "[SCSI] Fix uninitialized variable error in scsi_io_completion" > > 0eb6038: Revert "[SCSI] Fix error handling for DIF/DIX" > > 3cd94dd: Revert "[SCSI] scsi_lib: don't decrement busy counters when inserting commands" > > c27aed5: Revert "[SCSI] scsi_lib: fix DID_RESET status problems" > > > > I wasnt Cc:-ed on the updated patch AFAICS, so i didnt pick it > > up. > > Actually, you were cc'd, you probably just missed it. Correct, see my earlier reply to Alan Stern for the details of why it got missed. > > > So the real question is why does the -rt tree even have > > > patches not in the vanilla SCSI tree? This type of cockup > > > clearly demonstrates why it's a bad idea. > > > > Believe me, i have better things to do than to track down your > > regressions. I applied a fix/test patch sent to me by SCSI > > folks. > > Look, I've no problem with you collecting random patches. I > have a problem when you start pushing random SCSI patches into > other trees. [...] Both -tip and -rt are generic trees and there's a connection between them that the maintainers of both are one and the same set of people. So i'm not sure on what grounds you purport to be able to prevent fixes from flowing from -tip into -rt and vice versa. You have no monopoly on the propagation and testing of SCSI fixes. We picked up a v1 patch from the SCSI list and did not add nor remove anything from it. Yes, v1 was buggy and I missed the v2 patch because it had the same subject line and no easily visible differentiator that it was a v2 patch. In fact you should be happy that people are helping you out fixing your bugs. I never even thought of flaming anyone for having picked up a v1 scheduler fix and getting burned by it while a v2 existed. I find it unexplainable and irrational that you feel the need to do so for SCSI fixes. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
