Bug 183980 - [ata] Unreliable hotplug support with Intel Patsburg AHCI SATA controller
Summary: [ata] Unreliable hotplug support with Intel Patsburg AHCI SATA controller
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.0-BETA3
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-15 03:20 UTC by Marie Helene Kvello-Aune
Modified: 2021-06-10 13:13 UTC (History)
1 user (show)

See Also:


Attachments
file.txt (1.24 KB, text/plain)
2013-11-15 03:20 UTC, Marie Helene Kvello-Aune
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marie Helene Kvello-Aune 2013-11-15 03:20:00 UTC
Removing a hotplug-able drive tray connected to a hotplug-aware controller does not always properly destroy the device.
Mainboard: Supermicro X9SRL-F (http://www.supermicro.nl/products/motherboard/xeon/c600/x9srl-f.cfm)
CPU: Intel Xeon E5-1620v2 (http://ark.intel.com/products/75779/)

Example output when hotplug fails:
<remove from hotplug bay>
Nov 15 03:16:40 homer kernel: ada1 at ahcich1 bus 0 scbus3 target 0 lun 0
Nov 15 03:16:40 homer kernel: ada1: <SAMSUNG MZ7PD120HAFV-000DA DXM02W1Q> s/n xxx detached
<insert into hotplug bay>
Nov 15 03:20:32 homer kernel: cam_periph_alloc: attempt to re-allocate valid device ada1 rejected flags 0x118 refcount 2

Note the absence of 'Periph destroyed' in the above output.

If a port successfully handles hotplugging, it will keep doing so until next reboot, at which point it may or may not support hotplugging again.

Relevant dmesg output is attached

Fix: Patch attached with submission follows:
Comment 1 Marie Helene Kvello-Aune 2013-11-15 04:17:34 UTC
I've tried to reproduce the problem with FreeBSD 9.2-RELEASE (AMD64), but
have so far been unable to. I've tried 20 times across 5 reboots. I
therefore believe this may be a regression. The hardware in question will
be available for experimentation for a couple of weeks, so please let me
know if there's anything else I should do to pinpoint the error.
Comment 2 Marie Helene Kvello-Aune 2013-11-15 10:25:41 UTC
Following suggestions from mav@ on the FreeBSD forums (
http://forums.freebsd.org/showthread.php?t=43238), I've discovered that the
problem was somehow caused by SWAP being enabled on the device which was
being unplugged. Considering that 'top' output indicated no swap was being
used, and that the system had nearly 63 GB unused memory at the time, I
would be surprised if anything was swapped.

Although the issue is not what I initially thought it was, I still believe
this is a problem which needs resolving, as a hdd dying for whatever reason
should not make a port unavailable for what seems like an arbitary period
of time. (I have not yet managed to make the port work again by any other
way than a reboot, but I only left the system running for up to 15 minutes)
Comment 3 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:00:25 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped
Comment 4 Sergei Masharov 2021-06-10 13:13:30 UTC
Jun 10 16:09:20 <kern.crit> proxy kernel: cam_periph_alloc: attempt to re-allocate valid device ada1 rejected flags 0x118 refcount 2
Jun 10 16:09:20 <kern.crit> proxy kernel: adaasync: Unable to attach to new device due to status 0x6

13.0-RELEASE-p1 FreeBSD 13.0-RELEASE-p1

One disk is sometimes disapperas. Usually camcontrol reset/rescan works, but now after the reset/rescan device have appeared in devlist, but ada device was not created.