linux-kernel - Re: Regression? 2.6.23.16 -> 2.6.32.9: ide/libata HD recognition

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: <4B998516.1000606@gmail.com>
Date:	Thu, 11 Mar 2010 18:04:38 -0600
From:	Robert Hancock <hancockrwd@...il.com>
To:	CaT <cat@....com.au>
CC:	linux-kernel@...r.kernel.org
Subject: Re: Regression? 2.6.23.16 -> 2.6.32.9: ide/libata HD recognition

On 03/09/2010 10:16 PM, CaT wrote:
> Hi,
>
> Just had a strange situation with the above upgrade. It was done on an
> old server that used the serverworks ide driver. The IDE hw config under
> 2.6.23.16 was:
>
> hda:	HD
> hdb:	CDROM
> hdc:	empty
> hdd:	HD

That sounds like you had a slave with no master on the second IDE 
channel. That really isn't a wise configuration and is prone to break 
(some devices don't work in this setup, some BIOSes choke, etc.) since 
the standard doesn't really allow this (the spec says that support for 
this configuration is "host specific" and not mandatory).

There have been some reports about this breaking when moving to libata 
(not sure about newer versions of IDE). I'm not sure exactly what has 
changed to cause this, but it might not be possible to get around it 
without breaking other things (could be the 80-wire cable detection 
protocol is what changed things, but IIRC the reason it changed was the 
original code didn't follow the spec and didn't always work properly 
with some hardware).

Essentially, fixing the hardware config to set the drive for master if 
it's the only device on the channel is likely the best solution overall.

>
> After upgrade, using either IDE or libata the config changed to:
>
> hda:	HD
> hdb:	CDROM
> hdc:	empty
> hdd:	empty
>
> The BIOS recognised the disk. I went through 3 disks and it wasn't until
> I made the second HD a master that it was recognised. So now I have a
> 2.6.32.9 server, using the IDE subsystem with the following config:
>
> hda:	HD
> hdb:	CDROM
> hdc:	HD
> hdd:	empty
>
> Otherwise it does not work.
>
> I had an outage window that I already blew so I was not able to do
> any more diagnosis than what it took to get the system up.
>
> If anyone wants the full config I'll send. Otherwise:
>
> IDE subsystem (no libata subsystem configured):
>
> CONFIG_HAVE_IDE=y
> CONFIG_IDE=y
> CONFIG_IDE_XFER_MODE=y
> CONFIG_IDE_ATAPI=y
> CONFIG_IDE_GD=y
> CONFIG_IDE_GD_ATA=y
> CONFIG_BLK_DEV_IDECD=y
> CONFIG_BLK_DEV_IDECD_VERBOSE_ERRORS=y
> CONFIG_BLK_DEV_IDEACPI=y
> CONFIG_IDE_PROC_FS=y
> CONFIG_BLK_DEV_IDEDMA_SFF=y
> CONFIG_BLK_DEV_IDEPCI=y
> CONFIG_IDEPCI_PCIBUS_ORDER=y
> CONFIG_BLK_DEV_IDEDMA_PCI=y
> CONFIG_BLK_DEV_IDEDMA=y
> CONFIG_LEDS_TRIGGER_IDE_DISK=y
>
> libata kernel (no IDE subsystem configured):
>
> CONFIG_ATA=y
> CONFIG_ATA_VERBOSE_ERROR=y
> CONFIG_ATA_ACPI=y
> CONFIG_SATA_PMP=y
> CONFIG_ATA_SFF=y
> CONFIG_PATA_SERVERWORKS=y
>

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