linux-kernel - Re: Linux 2.6.20-rc1

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]

Message-Id: <200612142016.55286.s0348365@sms.ed.ac.uk>
Date:	Thu, 14 Dec 2006 20:16:55 +0000
From:	Alistair John Strachan <s0348365@....ed.ac.uk>
To:	Linus Torvalds <torvalds@...l.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jeff Garzik <jeff@...zik.org>,
	Jens Axboe <jens.axboe@...cle.com>
Subject: Re: Linux 2.6.20-rc1

On Thursday 14 December 2006 19:57, Linus Torvalds wrote:
> On Thu, 14 Dec 2006, Alistair John Strachan wrote:
> > `hddtemp' has stopped working on 2.6.20-rc1:
>
> Hmm. Can you do the strace on a working kernel too? For example, is it
> that the 0x30d ioctl (which is HDIO_GET_IDENTITY) used to work? If it's a
> SATA device, and you _used_ to use the PATA drivers, some of the old
> IDE-only ioctl's simply don't work when used in native SATA
> configurations.

I've always been using sata_nv and libata. All the drives in question are SATA 
devices, no configuration change other than this kernel has taken place.

Indeed, the configs are very similar. Find the configs, straces on both 
kernels, and the hddtemp binary (AMD64, I'm afraid) here:

http://devzero.co.uk/~alistair/2.6.20-rc1-hddtemp/

> [ Side note: I consider that to be a mis-feature, but it's not a new
>   regression, it's always been that way: different block subsystems have
>   had their own "private" ioctl spaces.
>
>   We've been moving more and more towards a unified space, and we could
>   probably make scsi_ioctl.c emulate at least _some_ of the HDIO_xxx calls
>   too, and try to support all the block ioctl's on all block devices
>   rather than have some that work only on some certain class of hardware.
>
>   But we're not there yet, and in the meantime it will actually make a
>   difference whether you use your disks through the kernel SCSI layer
>   (SATA and /dev/sdX) or through the IDE layer (IDE and /dev/hdX) ]
>
> On the other hand, this _sounds_ very much like a bug that should have
> been fixed before 2.6.20-rc1, which affected SG_IO.
>
> If you can do a "git bisect" on this, that would help a lot.

I'll do that if nobody comes up with anything obvious.

> (Btw, where is "hddtemp" from, anyway? Doesn't seem to be part of the
> standard set of tools I have on any of my systems)

http://www.guzu.net/linux/hddtemp.php

I run this in monitor mode, and then use the gkrellm plugin to keep an eye on 
the disk temperatures. It's worked well for years, until now.

-- 
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/