Prev: call_usermodehelper: call info->init() after set_user_nice()
Next: [PATCH -mm] call_usermodehelper: call info->init() after set_user_nice()
From: Bill Davidsen on 10 Mar 2010 13:50 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 > > 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: > Could you "ls /sys/block" and post? And /var/log/messages from the start to the last device found? Thanks. -- Bill Davidsen <davidsen(a)tmr.com> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Robert Hancock on 11 Mar 2010 19:10
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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |