lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 15 Dec 2006 01:41:08 +0000
From:	Alistair John Strachan <s0348365@....ed.ac.uk>
To:	Jens Axboe <jens.axboe@...cle.com>
Cc:	Linus Torvalds <torvalds@...l.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jeff Garzik <jeff@...zik.org>
Subject: Re: Linux 2.6.20-rc1

On Friday 15 December 2006 00:48, Alistair John Strachan wrote:
> On Thursday 14 December 2006 21:20, Jens Axboe wrote:
> > On Thu, Dec 14 2006, Alistair John Strachan wrote:
> > > Hi Jens,
> > >
> > > On Thursday 14 December 2006 20:48, Jens Axboe wrote:
> > > > On Thu, Dec 14 2006, Jens Axboe wrote:
> > > > > > I'll do that if nobody comes up with anything obvious.
> > > > >
> > > > > If you can just test 2.6.19-git1, then we'll know if it's the SG_IO
> > > > > patch again.
> > > >
> > > > Actually, you should test 2.6.19-git1 with this patch applied as
> > > > well.
> > >
> > > 2.6.19-git1 with FUJITA Tomonori's bio-leak fix doesn't break, and
> > > hddtemp continues to work fine:
> > >
> > > [root] 21:10 [~] hddtemp /dev/sda /dev/sdb /dev/sdc /dev/sdd
> > > /dev/sda: WDC WD2500KS-00MJB0: 29°C
> > > /dev/sdb: WDC WD2500KS-00MJB0: 27°C
> > > /dev/sdc: Maxtor 6B200M0: 28°C
> > > /dev/sdd: Maxtor 6B200M0: 26°C
> > >
> > > I've added the strace results to the URL previously posted, with the
> > > config.
> >
> > Then it is likely the sata updates, SG_IO is off the hook.
>
> I bisected all the way down to 0e75f9063f5c55fb0b0b546a7c356f8ec186825e,
> which git reckons is the culprit. I wasn't able to revert this commit to
> test, because it has conflicts.

Whatever the change is, it's subtle. I don't see the problem in git1+patch, 
but I know this kernel _includes_ this changeset.

In total isolation, v2.6.19..0e75f9063f5c55fb0b0b546a7c356f8ec186825e it 
breaks. Reverting just 0e75f9063f5c55fb0b0b546a7c356f8ec186825e, it works 
again.

So I think this is the source, but I can't explain why it "goes away" before 
git1 and "comes back" before 2.6.20-rc1.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ