When a SATA drive is plugged into a motherboard SATA port for the first time after booting, the device node (e.g. /dev/sdc) is properly created. When it is unplugged, the device node is properly removed. However, thereafter, no amount of plugging or unplugging on that SATA port will cause a device node to be created; the port effectively no longer exists. In Mandriva 2010.2, hot-plugging repeatedly worked correctly. See also the forum thread https://forums.mageia.org/en/viewtopic.php?f=8&t=2727 in which I posted that > My online research indicates that the following patch (which must not have > made it into the Mageia 2 release) should fix the regression introduced in > the Linux 3.3 kernel: > http://www.lingrok.org/xref/linux-linus/drivers/ata/libata-transport.c?r=0c8d32c27f5cf6e14ca14b4758d1e994eebd50fd > >A one-liner version was posted just before the full patch: >http://www.spinics.net/lists/linux-ide/msg43233.html # lspci 00:00.0 Host bridge: ATI Technologies Inc RX780/RX790 Chipset Host Bridge 00:02.0 PCI bridge: ATI Technologies Inc RD790 PCI to PCI bridge (external gfx0 port A) 00:0a.0 PCI bridge: ATI Technologies Inc RD790 PCI to PCI bridge (PCI express gpp port F) 00:11.0 SATA controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] 00:12.0 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI0 Controller 00:12.1 USB controller: ATI Technologies Inc SB7x0 USB OHCI1 Controller 00:12.2 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB EHCI Controller 00:13.0 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI0 Controller 00:13.1 USB controller: ATI Technologies Inc SB7x0 USB OHCI1 Controller 00:13.2 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB EHCI Controller 00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 3c) 00:14.1 IDE interface: ATI Technologies Inc SB7x0/SB8x0/SB9x0 IDE Controller 00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA) 00:14.3 ISA bridge: ATI Technologies Inc SB7x0/SB8x0/SB9x0 LPC host controller 00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge 00:14.5 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI2 Controller 00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor HyperTransport Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Miscellaneous Control 00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Link Control 01:00.0 VGA compatible controller: nVidia Corporation G98 [GeForce 8400 GS] (rev a1) 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02) 03:0e.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link)
I originally reported this in the mentioned thread. I can, of course, confirm this is a big problem. Further, I consider this to be a severe problem- having to reboot a server or important workstation is not a suitable situation. Many people (like me) use hot swappable SATA drives to perform regular backups. Also, I don't think this has nothing to do with powersave/suspend/resume as I am not using any of those.
CC: (none) => crxssi
We have a workaround using sysfs which works for both myself and MD: 1. Determine the appropriate "ataN" name for the SATA port, e.g. "ata5". Look in /var/log/messages or dmesg after plugging in the drive. 2. Locate the power-control entry for the port in sysfs: PORT=`find /sys/devices -name ataN | grep -v ata_port |head -1` CONTROL=$PORT/power/control 3. Write "on" to disable power management: sudo echo on >$CONTROL Note that the name of the device node may change the next time the drive is plugged in (it didn't for me, it did for MD).
I can confirm RB's posting, above, that the workaround does work. It is a pain to have to mess with, and end up with renumbered/relettered drives, but at least it avoids having to reboot the whole system.
thomas something for you ? (regarding comment 0)
CC: (none) => tmb
The problem remains/persists with the last kernel upgrade to 3.3.8-desktop-2.mga2 I am not sure why Mageia has still not patched the kernel.
Keywords: (none) => PATCH, TriagedCC: (none) => stormiAssignee: bugsquad => tmbSource RPM: (none) => kernel
This message is a reminder that Mageia 2 is nearing its end of life. Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- The Mageia Bugsquad
Mageia 2 changed to end-of-life (EOL) status on ''22 November''. Mageia 2 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- The Mageia Bugsquad
Status: NEW => RESOLVEDResolution: (none) => OLD