Hotplug drives on vt8251 with ahci module

Hotplug drives on vt8251 with ahci module

[Aalderd Bouwman]

Hello,

When I load module ahci when a drive is 'online' the drive is can be used 
normal. When I disconnect the drive EH doesn't recognize that action. When I 
reconnect the driver posts the following kernel-message:

ata2: exception Emask 0x10 SAct 0x0 SErr 0x40f0000 action 0x2 frozen
ata2: (irq_stat 0x04400040, connection status changed)
ata2: soft resetting port
ata2: SATA link down (SStatus 1 SControl 300)
ata2: failed to recover some devices, retrying in 5 secs

And I am not able to use the drive/port at all.
The driver will disable the ata-port.

The total kernel-log:

Jun 21 09:27:33 server libata version 1.30 loaded.
Jun 21 09:27:33 server ahci 0000:00:0f.0: version 1.3
Jun 21 09:27:33 server ACPI (acpi_bus-0192): Device `SATA]is not power 
manageable [20060310]
Jun 21 09:27:33 server ACPI: PCI Interrupt 0000:00:0f.0[B] -> Link [LNKB] -> 
GSI 10 (level, low) -> IRQ 10
Jun 21 09:27:37 server ahci 0000:00:0f.0: AHCI 0001.0000 32 slots 4 ports 3 
Gbps 0xf impl SATA mode
Jun 21 09:27:37 server ahci 0000:00:0f.0: flags: 64bit ncq pm led clo pmp pio 
slum part
Jun 21 09:27:37 server ata1: SATA max UDMA/133 cmd 0xE048AD00 ctl 0x0 bmdma 
0x0 irq 10
Jun 21 09:27:37 server ata2: SATA max UDMA/133 cmd 0xE048AD80 ctl 0x0 bmdma 
0x0 irq 10
Jun 21 09:27:37 server ata3: SATA max UDMA/133 cmd 0xE048AE00 ctl 0x0 bmdma 
0x0 irq 10
Jun 21 09:27:37 server ata4: SATA max UDMA/133 cmd 0xE048AE80 ctl 0x0 bmdma 
0x0 irq 10
Jun 21 09:27:37 server ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Jun 21 09:27:37 server ata1.00: cfg 49:2f00 82:346b 83:7d01 84:4023 85:3469 
86:3c01 87:4023 88:407f
Jun 21 09:27:37 server ata1.00: ATA-7, max UDMA/133, 156301488 sectors: LBA48 
NCQ (depth 0/32)
Jun 21 09:27:37 server ata1.00: configured for UDMA/133
Jun 21 09:27:37 server scsi0 : ahci
Jun 21 09:27:38 server ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Jun 21 09:27:38 server ata2.00: cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c69 
86:3a01 87:4003 88:007f
Jun 21 09:27:38 server ata2.00: ATA-7, max UDMA/133, 160086528 sectors: LBA
Jun 21 09:27:38 server ata2.00: configured for UDMA/133
Jun 21 09:27:38 server scsi1 : ahci
Jun 21 09:27:38 server ata3: SATA link down (SStatus 0 SControl 300)
Jun 21 09:27:38 server scsi2 : ahci
Jun 21 09:27:38 server ata4: SATA link down (SStatus 0 SControl 300)
Jun 21 09:27:38 server scsi3 : ahci
Jun 21 09:27:38 server Vendor: ATA       Model: ST3808110AS       Rev: 3.AA
Jun 21 09:27:38 server Type:   Direct-Access                      ANSI SCSI 
revision: 05
Jun 21 09:27:38 server SCSI device sda: 156301488 512-byte hdwr sectors (80026 
MB)
Jun 21 09:27:38 server sda: Write Protect is off
Jun 21 09:27:38 server sda: Mode Sense: 00 3a 00 00
Jun 21 09:27:38 server SCSI device sda: drive cache: write back
Jun 21 09:27:38 server SCSI device sda: 156301488 512-byte hdwr sectors (80026 
MB)
Jun 21 09:27:38 server sda: Write Protect is off
Jun 21 09:27:38 server sda: Mode Sense: 00 3a 00 00
Jun 21 09:27:38 server SCSI device sda: drive cache: write back
Jun 21 09:27:38 server sda: sda1 sda2 sda3 sda4 < sda5 sda6 >
Jun 21 09:27:38 server sd 0:0:0:0: Attached scsi disk sda
Jun 21 09:27:38 server sd 0:0:0:0: Attached scsi generic sg0 type 0
Jun 21 09:27:38 server Vendor: ATA       Model: Maxtor 6Y080M0    Rev: YAR5
Jun 21 09:27:38 server Type:   Direct-Access                      ANSI SCSI 
revision: 05
Jun 21 09:27:38 server SCSI device sdb: 160086528 512-byte hdwr sectors (81964 
MB)
Jun 21 09:27:38 server sdb: Write Protect is off
Jun 21 09:27:38 server sdb: Mode Sense: 00 3a 00 00
Jun 21 09:27:38 server SCSI device sdb: drive cache: write back
Jun 21 09:27:38 server SCSI device sdb: 160086528 512-byte hdwr sectors (81964 
MB)
Jun 21 09:27:38 server sdb: Write Protect is off
Jun 21 09:27:38 server sdb: Mode Sense: 00 3a 00 00
Jun 21 09:27:38 server SCSI device sdb: drive cache: write back
Jun 21 09:27:38 server sdb: sdb1 sdb2
Jun 21 09:27:38 server sd 1:0:0:0: Attached scsi disk sdb
Jun 21 09:27:38 server sd 1:0:0:0: Attached scsi generic sg1 type 0
Jun 21 09:29:04 server ata2: exception Emask 0x10 SAct 0x0 SErr 0x40f0000 
action 0x2 frozen
Jun 21 09:29:04 server ata2: (irq_stat 0x04400040, connection status changed)
Jun 21 09:29:04 server ata2: soft resetting port
Jun 21 09:29:04 server ata2: SATA link down (SStatus 1 SControl 300)
Jun 21 09:29:04 server ata2: failed to recover some devices, retrying in 5 
secs
Jun 21 09:29:09 server ata2: hard resetting port
Jun 21 09:29:16 server ata2: port is slow to respond, please be patient
Jun 21 09:29:39 server ata2: port failed to respond (30 secs)
Jun 21 09:29:39 server ata2: COMRESET failed (device not ready)
Jun 21 09:29:39 server ata2: hardreset failed, retrying in 5 secs
Jun 21 09:29:44 server ata2: hard resetting port
Jun 21 09:29:52 server ata2: port is slow to respond, please be patient
Jun 21 09:30:15 server ata2: port failed to respond (30 secs)
Jun 21 09:30:15 server ata2: COMRESET failed (device not ready)
Jun 21 09:30:15 server ata2: hardreset failed, retrying in 5 secs
Jun 21 09:30:20 server ata2: hard resetting port
Jun 21 09:30:27 server ata2: port is slow to respond, please be patient
Jun 21 09:30:50 server ata2: port failed to respond (30 secs)
Jun 21 09:30:50 server ata2: COMRESET failed (device not ready)
Jun 21 09:30:50 server ata2: reset failed, giving up
Jun 21 09:30:50 server ata2.00: disabled
Jun 21 09:30:50 server ata2: EH complete

When I try to fdisk the drive:
Jun 21 09:31:24 server sd 1:0:0:0: SCSI error: return code = 0x40000
Jun 21 09:31:24 server end_request: I/O error, dev sdb, sector 0
Jun 21 09:31:24 server Buffer I/O error on device sdb, logical block 0
Jun 21 09:31:24 server sd 1:0:0:0: SCSI error: return code = 0x40000
Jun 21 09:31:24 server end_request: I/O error, dev sdb, sector 8
Jun 21 09:31:24 server Buffer I/O error on device sdb, logical block 1
Jun 21 09:31:24 server sd 1:0:0:0: SCSI error: return code = 0x40000
Jun 21 09:31:24 server end_request: I/O error, dev sdb, sector 16
Jun 21 09:31:24 server Buffer I/O error on device sdb, logical block 2
Jun 21 09:31:24 server sd 1:0:0:0: SCSI error: return code = 0x40000
Jun 21 09:31:24 server end_request: I/O error, dev sdb, sector 24
Jun 21 09:31:24 server Buffer I/O error on device sdb, logical block 3
Jun 21 09:31:24 server sd 1:0:0:0: SCSI error: return code = 0x40000
Jun 21 09:31:24 server end_request: I/O error, dev sdb, sector 0
Jun 21 09:31:24 server Buffer I/O error on device sdb, logical block 0
Jun 21 09:31:29 server sd 1:0:0:0: SCSI error: return code = 0x40000
Jun 21 09:31:29 server end_request: I/O error, dev sdb, sector 0
Jun 21 09:31:29 server Buffer I/O error on device sdb, logical block 0
Jun 21 09:31:29 server sd 1:0:0:0: SCSI error: return code = 0x40000
Jun 21 09:31:29 server end_request: I/O error, dev sdb, sector 8
Jun 21 09:31:29 server Buffer I/O error on device sdb, logical block 1
Jun 21 09:31:29 server sd 1:0:0:0: SCSI error: return code = 0x40000
Jun 21 09:31:29 server end_request: I/O error, dev sdb, sector 16
Jun 21 09:31:29 server Buffer I/O error on device sdb, logical block 2
Jun 21 09:31:29 server sd 1:0:0:0: SCSI error: return code = 0x40000
Jun 21 09:31:29 server end_request: I/O error, dev sdb, sector 24
Jun 21 09:31:29 server Buffer I/O error on device sdb, logical block 3
Jun 21 09:31:29 server sd 1:0:0:0: SCSI error: return code = 0x40000
Jun 21 09:31:29 server end_request: I/O error, dev sdb, sector 0
Jun 21 09:31:29 server Buffer I/O error on device sdb, logical block 0

Remove the ahci module:
Jun 21 09:32:17 server ACPI: PCI interrupt for device 0000:00:0f.0 disabled

Here I disconnect both drives connected to the controller.
After the second/third port-reset I also do rmmod ahci:

Jun 21 09:12:02 server ahci 0000:00:0f.0: version 1.3
Jun 21 09:12:02 server ACPI: PCI Interrupt 0000:00:0f.0[B] -> Link [LNKB] -> 
GSI 10 (level, low) -> IRQ 10
Jun 21 09:12:06 server ahci 0000:00:0f.0: AHCI 0001.0000 32 slots 4 ports 3 
Gbps 0xf impl SATA mode
Jun 21 09:12:06 server ahci 0000:00:0f.0: flags: 64bit ncq pm led clo pmp pio 
slum part 
Jun 21 09:12:06 server ata9: SATA max UDMA/133 cmd 0xE0488D00 ctl 0x0 bmdma 
0x0 irq 10
Jun 21 09:12:06 server ata10: SATA max UDMA/133 cmd 0xE0488D80 ctl 0x0 bmdma 
0x0 irq 10
Jun 21 09:12:06 server ata11: SATA max UDMA/133 cmd 0xE0488E00 ctl 0x0 bmdma 
0x0 irq 10
Jun 21 09:12:06 server ata12: SATA max UDMA/133 cmd 0xE0488E80 ctl 0x0 bmdma 
0x0 irq 10
Jun 21 09:12:07 server ata9: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Jun 21 09:12:07 server ata9.00: cfg 49:2f00 82:346b 83:7d01 84:4023 85:3469 
86:3c01 87:4023 88:407f
Jun 21 09:12:07 server ata9.00: ATA-7, max UDMA/133, 156301488 sectors: LBA48 
NCQ (depth 0/32)
Jun 21 09:12:07 server ata9.00: configured for UDMA/133
Jun 21 09:12:07 server scsi8 : ahci
Jun 21 09:12:07 server ata10: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Jun 21 09:12:07 server ata10.00: cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c69 
86:3a01 87:4003 88:007f
Jun 21 09:12:07 server ata10.00: ATA-7, max UDMA/133, 160086528 sectors: LBA 
Jun 21 09:12:07 server ata10.00: configured for UDMA/133
Jun 21 09:12:07 server scsi9 : ahci
Jun 21 09:12:07 server ata11: SATA link down (SStatus 0 SControl 300)
Jun 21 09:12:07 server scsi10 : ahci
Jun 21 09:12:07 server ata12: SATA link down (SStatus 0 SControl 300)
Jun 21 09:12:07 server scsi11 : ahci
Jun 21 09:12:07 server Vendor: ATA       Model: ST3808110AS       Rev: 3.AA
Jun 21 09:12:07 server Type:   Direct-Access                      ANSI SCSI 
revision: 05
Jun 21 09:12:07 server SCSI device sda: 156301488 512-byte hdwr sectors (80026 
MB)
Jun 21 09:12:07 server sda: Write Protect is off
Jun 21 09:12:07 server sda: Mode Sense: 00 3a 00 00
Jun 21 09:12:07 server SCSI device sda: drive cache: write back
Jun 21 09:12:07 server SCSI device sda: 156301488 512-byte hdwr sectors (80026 
MB)
Jun 21 09:12:07 server sda: Write Protect is off
Jun 21 09:12:07 server sda: Mode Sense: 00 3a 00 00
Jun 21 09:12:07 server SCSI device sda: drive cache: write back
Jun 21 09:12:07 server sda: sda1 sda2 sda3 sda4 < sda5 sda6 >
Jun 21 09:12:07 server sd 8:0:0:0: Attached scsi disk sda
Jun 21 09:12:07 server sd 8:0:0:0: Attached scsi generic sg0 type 0
Jun 21 09:12:07 server Vendor: ATA       Model: Maxtor 6Y080M0    Rev: YAR5
Jun 21 09:12:07 server Type:   Direct-Access                      ANSI SCSI 
revision: 05
Jun 21 09:12:07 server SCSI device sdb: 160086528 512-byte hdwr sectors (81964 
MB)
Jun 21 09:12:07 server sdb: Write Protect is off
Jun 21 09:12:07 server sdb: Mode Sense: 00 3a 00 00
Jun 21 09:12:07 server SCSI device sdb: drive cache: write back
Jun 21 09:12:07 server SCSI device sdb: 160086528 512-byte hdwr sectors (81964 
MB)
Jun 21 09:12:07 server sdb: Write Protect is off
Jun 21 09:12:07 server sdb: Mode Sense: 00 3a 00 00
Jun 21 09:12:07 server SCSI device sdb: drive cache: write back
Jun 21 09:12:07 server sdb: sdb1 sdb2
Jun 21 09:12:07 server sd 9:0:0:0: Attached scsi disk sdb
Jun 21 09:12:07 server sd 9:0:0:0: Attached scsi generic sg1 type 0
Jun 21 09:13:32 server ata9: exception Emask 0x10 SAct 0x0 SErr 0x41f0000 
action 0x2 frozen
Jun 21 09:13:32 server ata9: (irq_stat 0x04400040, connection status changed)
Jun 21 09:13:32 server ata9: soft resetting port
Jun 21 09:13:32 server ata9: SATA link down (SStatus 1 SControl 300)
Jun 21 09:13:32 server ata9: failed to recover some devices, retrying in 5 
secs
Jun 21 09:13:37 server ata9: hard resetting port
Jun 21 09:13:45 server ata9: port is slow to respond, please be patient
Jun 21 09:13:54 server ata10: exception Emask 0x10 SAct 0x0 SErr 0x4070000 
action 0x2 frozen
Jun 21 09:13:54 server ata10: (irq_stat 0x04400040, connection status changed)
Jun 21 09:13:54 server ata10: soft resetting port
Jun 21 09:13:54 server ata10: SATA link down (SStatus 1 SControl 300)
Jun 21 09:13:54 server ata10: failed to recover some devices, retrying in 5 
secs
Jun 21 09:13:59 server ata10: hard resetting port
Jun 21 09:14:06 server ata10: port is slow to respond, please be patient
Jun 21 09:14:08 server ata9: port failed to respond (30 secs)
Jun 21 09:14:08 server ata9: COMRESET failed (device not ready)
Jun 21 09:14:08 server ata9: hardreset failed, retrying in 5 secs
Jun 21 09:14:13 server ata9: hard resetting port
Jun 21 09:14:20 server ata9: port is slow to respond, please be patient
Jun 21 09:14:29 server ata10: port failed to respond (30 secs)
Jun 21 09:14:29 server ata10: COMRESET failed (device not ready)
Jun 21 09:14:29 server ata10: hardreset failed, retrying in 5 secs
Jun 21 09:14:34 server ata10: hard resetting port
Jun 21 09:14:41 server ata10: port is slow to respond, please be patient
Jun 21 09:14:43 server ata9: port failed to respond (30 secs)
Jun 21 09:14:43 server ata9: COMRESET failed (device not ready)
Jun 21 09:14:43 server ata9: hardreset failed, retrying in 5 secs
Jun 21 09:14:48 server ata9: hard resetting port
Jun 21 09:14:55 server ata9: port is slow to respond, please be patient
Jun 21 09:15:04 server ata10: port failed to respond (30 secs)
Jun 21 09:15:04 server ata10: COMRESET failed (device not ready)
Jun 21 09:15:04 server ata10: hardreset failed, retrying in 5 secs
Jun 21 09:15:09 server ata10: hard resetting port
Jun 21 09:15:16 server ata10: port is slow to respond, please be patient
Jun 21 09:15:18 server ata9: port failed to respond (30 secs)
Jun 21 09:15:18 server ata9: COMRESET failed (device not ready)
Jun 21 09:15:18 server ata9: reset failed, giving up
Jun 21 09:15:18 server ata9: EH pending after completion, repeating EH (cnt=4)
Jun 21 09:15:18 server ata9: exception Emask 0x10 SAct 0x0 SErr 0x4070000 
action 0x2 frozen
Jun 21 09:15:18 server ata9: (irq_stat 0x00000040, connection status changed)
Jun 21 09:15:18 server ata9: soft resetting port
Jun 21 09:15:18 server BUG: unable to handle kernel NULL pointer dereference 
at virtual address 00000010
Jun 21 09:15:18 server printing eip:
Jun 21 09:15:18 server e04926cc
Jun 21 09:15:18 server *pde = 00000000
Jun 21 09:15:18 server Oops: 0000 [#1]
Jun 21 09:15:18 server last sysfs file: /block/sdb/sdb2/dev
Jun 21 09:15:18 server Modules linked in: ahci libata cls_u32 sch_htb 
xt_tcpudp iptable_filter iptable_nat ip_tables x_tables ip_nat_irc 
ip_conntrack_irc ip_nat_ftp ip_nat ip_conntrack_ftp w83627ehf i2c_isa 
i2c_core 3c59x
Jun 21 09:15:18 server CPU:    0
Jun 21 09:15:18 server EIP:    0060:[<e04926cc>]    Not tainted VLI
Jun 21 09:15:18 server EFLAGS: 00010246   (2.6.17-rc5-mm2 #2) 
Jun 21 09:15:18 server EIP is at ahci_tf_read+0xa/0x19 [ahci]
Jun 21 09:15:18 server eax: 00000000   ebx: e049382f   ecx: de36c29c   edx: 
00000000
Jun 21 09:15:18 server esi: de36c29c   edi: 00000000   ebp: e0488d00   esp: 
de43ce84
Jun 21 09:15:18 server ds: 007b   es: 007b   ss: 0068
Jun 21 09:15:18 server Process scsi_eh_8 (pid: 15546, threadinfo=de43c000 
task=c66ed550)
Jun 21 09:15:18 server Stack: e0492455 de36c29c de43ce94 00000000 0000000a 
de36c380 00000246 00000046 
Jun 21 09:15:18 server fffffecc 0000001a de43cecc c0110a49 de43cefc de36c380 
de36c29c de36c29c 
Jun 21 09:15:18 server e04aa50e de36c29c de43cefc e04923f1 e04b0de3 de36c29c 
e04923f1 de43cefc 
Jun 21 09:15:18 server Call Trace:
Jun 21 09:15:18 server <e0492455> ahci_softreset+0x64/0x1d1 [ahci]  <c0110a49> 
__wake_up+0x14/0x1e
Jun 21 09:15:18 server <e04aa50e> ata_do_reset+0x1b/0x4d [libata]  <e04923f1> 
ahci_softreset+0x0/0x1d1 [ahci]
Jun 21 09:15:18 server <e04b0de3> ata_eh_reset+0x78/0xff [libata]  <e04923f1> 
ahci_softreset+0x0/0x1d1 [ahci]
Jun 21 09:15:18 server <e04b0f96> ata_eh_recover+0x70/0x1b3 [libata]  
<e04923f1> ahci_softreset+0x0/0x1d1 [ahci]
Jun 21 09:15:18 server <e04925c2> ahci_hardreset+0x0/0x4c [ahci]  <e049260e> 
ahci_postreset+0x0/0x3c [ahci]
Jun 21 09:15:18 server <e049260e> ahci_postreset+0x0/0x3c [ahci]  <e04925c2> 
ahci_hardreset+0x0/0x4c [ahci]
Jun 21 09:15:18 server <e04923f1> ahci_softreset+0x0/0x1d1 [ahci]  <e04b1171> 
ata_do_eh+0x29/0x3c [libata]
Jun 21 09:15:18 server <e04923f1> ahci_softreset+0x0/0x1d1 [ahci]  <e04925c2> 
ahci_hardreset+0x0/0x4c [ahci]
Jun 21 09:15:18 server <e049260e> ahci_postreset+0x0/0x3c [ahci]  <e0492c87> 
ahci_error_handler+0x2e/0x33 [ahci]
Jun 21 09:15:18 server <e04923f1> ahci_softreset+0x0/0x1d1 [ahci]  <e04925c2> 
ahci_hardreset+0x0/0x4c [ahci]
Jun 21 09:15:18 server <e049260e> ahci_postreset+0x0/0x3c [ahci]  <e04affe5> 
ata_scsi_error+0x145/0x26a [libata]
Jun 21 09:15:18 server <c0249a4c> scsi_error_handler+0x0/0x10d  <c0249af4> 
scsi_error_handler+0xa8/0x10d
Jun 21 09:15:18 server <c0122f1a> kthread+0x79/0xa3  <c0122ea1> 
kthread+0x0/0xa3
Jun 21 09:15:18 server <c01012e5> kernel_thread_helper+0x5/0xb 
Jun 21 09:15:18 server Code: 49 e0 68 bb a1 4a e0 56 e8 92 7e 01 00 83 c4 18 
5b 5e c3 8b 44 24 04 8b 40 28 8b 40 20 0f b6 c0 c3 8b 44 24 04 8b 80 c0 1f 00 
00 <8b> 40 10 83 c0 40 89 44 24 04 e9 ae 59 01 00 55 31 ed 57 56 53 
Jun 21 09:15:18 server EIP: [<e04926cc>] ahci_tf_read+0xa/0x19 [ahci] SS:ESP 
0068:de43ce84
Jun 21 09:15:40 server <3>ata10: port failed to respond (30 secs)
Jun 21 09:15:40 server ata10: COMRESET failed (device not ready)
Jun 21 09:15:40 server ata10: reset failed, giving up
Jun 21 09:15:40 server ata10.00: disabled
Jun 21 09:15:40 server ata10: EH complete

Aalderd Bouwman.

Re: Hotplug drives on vt8251 with ahci module

[Tejun Heo]

Aalderd Bouwman wrote:
> Hello,
> 
> When I load module ahci when a drive is 'online' the drive is can be used 
> normal. When I disconnect the drive EH doesn't recognize that action. When I 
> reconnect the driver posts the following kernel-message:

I'm getting to dislike this via controller.  Again, the controller seems 
to lock up completely on hotplug events.  It might be that the current 
ahci's EH behavior just doesn't fit the via controller as the controller 
seems to lock up similarly in both NCQ and this case.  Maybe it doesn't 
like engine restart sequence (which, BTW, are all done in accordance to 
the AHCI spec).

> Here I disconnect both drives connected to the controller.
> After the second/third port-reset I also do rmmod ahci:
[--snip--]
> Jun 21 09:15:18 server BUG: unable to handle kernel NULL pointer dereference 
> at virtual address 00000010
> Jun 21 09:15:18 server printing eip:
> Jun 21 09:15:18 server e04926cc
> Jun 21 09:15:18 server *pde = 00000000
> Jun 21 09:15:18 server Oops: 0000 [#1]
> Jun 21 09:15:18 server last sysfs file: /block/sdb/sdb2/dev
> Jun 21 09:15:18 server Modules linked in: ahci libata cls_u32 sch_htb 
> xt_tcpudp iptable_filter iptable_nat ip_tables x_tables ip_nat_irc 
> ip_conntrack_irc ip_nat_ftp ip_nat ip_conntrack_ftp w83627ehf i2c_isa 
> i2c_core 3c59x
> Jun 21 09:15:18 server CPU:    0
> Jun 21 09:15:18 server EIP:    0060:[<e04926cc>]    Not tainted VLI
> Jun 21 09:15:18 server EFLAGS: 00010246   (2.6.17-rc5-mm2 #2) 
> Jun 21 09:15:18 server EIP is at ahci_tf_read+0xa/0x19 [ahci]
> Jun 21 09:15:18 server eax: 00000000   ebx: e049382f   ecx: de36c29c   edx: 
> 00000000
> Jun 21 09:15:18 server esi: de36c29c   edi: 00000000   ebp: e0488d00   esp: 
> de43ce84
> Jun 21 09:15:18 server ds: 007b   es: 007b   ss: 0068
> Jun 21 09:15:18 server Process scsi_eh_8 (pid: 15546, threadinfo=de43c000 
> task=c66ed550)
> Jun 21 09:15:18 server Stack: e0492455 de36c29c de43ce94 00000000 0000000a 
> de36c380 00000246 00000046 
> Jun 21 09:15:18 server fffffecc 0000001a de43cecc c0110a49 de43cefc de36c380 
> de36c29c de36c29c 
> Jun 21 09:15:18 server e04aa50e de36c29c de43cefc e04923f1 e04b0de3 de36c29c 
> e04923f1 de43cefc 
> Jun 21 09:15:18 server Call Trace:
> Jun 21 09:15:18 server <e0492455> ahci_softreset+0x64/0x1d1 [ahci]  <c0110a49> 
> __wake_up+0x14/0x1e
> Jun 21 09:15:18 server <e04aa50e> ata_do_reset+0x1b/0x4d [libata]  <e04923f1> 
> ahci_softreset+0x0/0x1d1 [ahci]
> Jun 21 09:15:18 server <e04b0de3> ata_eh_reset+0x78/0xff [libata]  <e04923f1> 

But, this is a driver bug.  I tried pretty hard to prevent this from 
happening.  Apparently, I screwed up.  If it's not too much trouble, can 
you please try libata-dev #upstream and see how it works with similar 
unloading scenario.  I'll try to reproduce it here but I wanna know for 
sure that the latest devel tree has the same issue.

Even if you're not familiar w/ git, accessing libata-dev #upstream is 
actually quite simple.

1. install git (on debian, just install git-core package)
2. $ git-clone git://git.kernel.org/pub/scm/linux/kernel/\
    git/jgarzik/libata-dev.git libata-dev
3. $ cd libata-dev
4. $ git-checkout -f upstream
5. copy over your .config and build.

-- 
tejun

Re: Hotplug drives on vt8251 with ahci module

[Aalderd Bouwman]

Hello Tejun,

Is the NCQ-patch already in libata-dev git and how could I update my 
libata-dev tree?

About hotplug in libata-dev:
Now when I load the driver and the drive is turned on and I turned of the 
drive:

ahci 0000:00:0f.0: version 1.3
ACPI: PCI Interrupt 0000:00:0f.0[B] -> Link [LNKB] -> GSI 10 (level, low) -> 
IRQ 10
ahci 0000:00:0f.0: AHCI 0001.0000 32 slots 4 ports 3 Gbps 0xf impl SATA mode
ahci 0000:00:0f.0: flags: 64bit ncq pm led clo pmp pio slum part
ata9: SATA max UDMA/133 cmd 0xE0486D00 ctl 0x0 bmdma 0x0 irq 10
ata10: SATA max UDMA/133 cmd 0xE0486D80 ctl 0x0 bmdma 0x0 irq 10
ata11: SATA max UDMA/133 cmd 0xE0486E00 ctl 0x0 bmdma 0x0 irq 10
ata12: SATA max UDMA/133 cmd 0xE0486E80 ctl 0x0 bmdma 0x0 irq 10
scsi8 : ahci
ata9: SATA link down (SStatus 0 SControl 300)
scsi9 : ahci
ata10: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata10.00: cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c69 86:3a01 87:4003 88:007f
ata10.00: ATA-7, max UDMA/133, 160086528 sectors: LBA
ata10.00: configured for UDMA/133
scsi10 : ahci
ata11: SATA link down (SStatus 0 SControl 300)
scsi11 : ahci
ata12: SATA link down (SStatus 0 SControl 300)
  Vendor: ATA       Model: Maxtor 6Y080M0    Rev: YAR5
  Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sda: 160086528 512-byte hdwr sectors (81964 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 160086528 512-byte hdwr sectors (81964 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
 sda: sda1 sda2
sd 9:0:0:0: Attached scsi disk sda
sd 9:0:0:0: Attached scsi generic sg0 type 0
ReiserFS: sda1: found reiserfs format "3.6" with standard journal
ReiserFS: sda1: using ordered data mode
ReiserFS: sda1: journal params: device sda1, size 8192, journal first block 
18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sda1: checking transaction log (sda1)
ReiserFS: sda1: Using r5 hash to sort names
ata10: exception Emask 0x10 SAct 0x0 SErr 0x30000 action 0x2 frozen
ata10: (irq_stat 0x04400000, PHY RDY changed)
ata10: soft resetting port
ata10: SATA link down (SStatus 1 SControl 300)
ata10: failed to recover some devices, retrying in 5 secs
ata10: hard resetting port
ata10: SATA link down (SStatus 0 SControl 300)
ata10: failed to recover some devices, retrying in 5 secs
ata10: hard resetting port
ata10: SATA link down (SStatus 0 SControl 300)
ata10.00: disabled
ata10: EH complete
ata10.00: detaching (SCSI 9:0:0:0)

Now I turn on the drive and turned him off when I see 'soft resetting port':
ata10: exception Emask 0x10 SAct 0x0 SErr 0x4060000 action 0x2 frozen
ata10: (irq_stat 0x00000040, connection status changed)
ata10: waiting for device to spin up (8 secs)
ata10: soft resetting port
ata10: port is slow to respond, please be patient
ata10: port failed to respond (30 secs)
ata10: softreset failed (device not ready)
ata10: softreset failed, retrying in 5 secs
ata10: hard resetting port
ata10: SATA link down (SStatus 0 SControl 300)
ata10: EH complete

And when I turned on the drive and waiting:
ata10: exception Emask 0x10 SAct 0x0 SErr 0x4060000 action 0x2 frozen
ata10: (irq_stat 0x00000040, connection status changed)
ata10: waiting for device to spin up (8 secs)
ata10: soft resetting port
ata10: port is slow to respond, please be patient
ata10: port failed to respond (30 secs)
ata10: softreset failed (device not ready)
ata10: softreset failed, retrying in 5 secs
ata10: hard resetting port
ata10: port is slow to respond, please be patient
ata10: port failed to respond (30 secs)
ata10: COMRESET failed (device not ready)
ata10: hardreset failed, retrying in 5 secs
ata10: hard resetting port
ata10: port is slow to respond, please be patient
ata10: port failed to respond (30 secs)
ata10: COMRESET failed (device not ready)
ata10: reset failed, giving up
ata10: EH complete

Now the port is disabled by the driver :'( so I am unable to use this port for 
an another drive and I think that is not what you want. When this module 
is 'build in' you should reboot your machine.

Aalderd Bouwman.

On Wednesday 21 June 2006 16:01, Tejun Heo wrote:
> Aalderd Bouwman wrote:
> > Hello,
> >
> > When I load module ahci when a drive is 'online' the drive is can be used
> > normal. When I disconnect the drive EH doesn't recognize that action.
> > When I reconnect the driver posts the following kernel-message:
>
> I'm getting to dislike this via controller.  Again, the controller seems
> to lock up completely on hotplug events.  It might be that the current
> ahci's EH behavior just doesn't fit the via controller as the controller
> seems to lock up similarly in both NCQ and this case.  Maybe it doesn't
> like engine restart sequence (which, BTW, are all done in accordance to
> the AHCI spec).
>
> > Here I disconnect both drives connected to the controller.
> > After the second/third port-reset I also do rmmod ahci:
>
> [--snip--]
>
> > Jun 21 09:15:18 server BUG: unable to handle kernel NULL pointer
> > dereference at virtual address 00000010
> > Jun 21 09:15:18 server printing eip:
> > Jun 21 09:15:18 server e04926cc
> > Jun 21 09:15:18 server *pde = 00000000
> > Jun 21 09:15:18 server Oops: 0000 [#1]
> > Jun 21 09:15:18 server last sysfs file: /block/sdb/sdb2/dev
> > Jun 21 09:15:18 server Modules linked in: ahci libata cls_u32 sch_htb
> > xt_tcpudp iptable_filter iptable_nat ip_tables x_tables ip_nat_irc
> > ip_conntrack_irc ip_nat_ftp ip_nat ip_conntrack_ftp w83627ehf i2c_isa
> > i2c_core 3c59x
> > Jun 21 09:15:18 server CPU:    0
> > Jun 21 09:15:18 server EIP:    0060:[<e04926cc>]    Not tainted VLI
> > Jun 21 09:15:18 server EFLAGS: 00010246   (2.6.17-rc5-mm2 #2)
> > Jun 21 09:15:18 server EIP is at ahci_tf_read+0xa/0x19 [ahci]
> > Jun 21 09:15:18 server eax: 00000000   ebx: e049382f   ecx: de36c29c  
> > edx: 00000000
> > Jun 21 09:15:18 server esi: de36c29c   edi: 00000000   ebp: e0488d00  
> > esp: de43ce84
> > Jun 21 09:15:18 server ds: 007b   es: 007b   ss: 0068
> > Jun 21 09:15:18 server Process scsi_eh_8 (pid: 15546, threadinfo=de43c000
> > task=c66ed550)
> > Jun 21 09:15:18 server Stack: e0492455 de36c29c de43ce94 00000000
> > 0000000a de36c380 00000246 00000046
> > Jun 21 09:15:18 server fffffecc 0000001a de43cecc c0110a49 de43cefc
> > de36c380 de36c29c de36c29c
> > Jun 21 09:15:18 server e04aa50e de36c29c de43cefc e04923f1 e04b0de3
> > de36c29c e04923f1 de43cefc
> > Jun 21 09:15:18 server Call Trace:
> > Jun 21 09:15:18 server <e0492455> ahci_softreset+0x64/0x1d1 [ahci] 
> > <c0110a49> __wake_up+0x14/0x1e
> > Jun 21 09:15:18 server <e04aa50e> ata_do_reset+0x1b/0x4d [libata] 
> > <e04923f1> ahci_softreset+0x0/0x1d1 [ahci]
> > Jun 21 09:15:18 server <e04b0de3> ata_eh_reset+0x78/0xff [libata] 
> > <e04923f1>
>
> But, this is a driver bug.  I tried pretty hard to prevent this from
> happening.  Apparently, I screwed up.  If it's not too much trouble, can
> you please try libata-dev #upstream and see how it works with similar
> unloading scenario.  I'll try to reproduce it here but I wanna know for
> sure that the latest devel tree has the same issue.
>
> Even if you're not familiar w/ git, accessing libata-dev #upstream is
> actually quite simple.
>
> 1. install git (on debian, just install git-core package)
> 2. $ git-clone git://git.kernel.org/pub/scm/linux/kernel/\
>     git/jgarzik/libata-dev.git libata-dev
> 3. $ cd libata-dev
> 4. $ git-checkout -f upstream
> 5. copy over your .config and build.

Re: Hotplug drives on vt8251 with ahci module

[Tejun Heo]

Aalderd Bouwman wrote:
> Hello Tejun,
> 
> Is the NCQ-patch already in libata-dev git and how could I update my 
> libata-dev tree?

No, the turn-off-NCQ-for-vt8251 patch isn't yet in libata-dev #upstream. 
  To apply the patch, simply checkout #upstream and apply the patch.

> Now the port is disabled by the driver :'( so I am unable to use this port for 
> an another drive and I think that is not what you want. When this module 
> is 'build in' you should reboot your machine.

You can tell the driver to rescan by issuing scan request via sysfs. 
For instruction, please read the following.

http://home-tj.org/wiki/index.php/Libata-tj-stable#README

About the disabling on hardreset failure...  Maybe there is some room 
for improvement - e.g. leave PHY status interrupts alive if it's not 
causing interrupt storm, but I'm not sure whether the benefits would 
outweigh the cost.

Leaving the port frozen (disabled & interrupts plugged) is a safety 
measure libata implements.  The driver isn't sure in what state the 
controller and the attached device are in as they are not responding 
even to the 'hard' reset, so it assumes the worst and shuns the port.

As I wrote above, you can ask libata to retry by explicitly telling 
libata to rescan the bus.  I thought that should be enough when I was 
implementing it.  At any rate, I doubt it will help your case as your 
controller gets completely stuck during EH and only controller-wide 
reset brings it back.

Also, I checked and the oops you've reported earlier shouldn't happen in 
the current #upstream.  It's been taken care of when the hotplug support 
was added.  So, you should at least be able to load and unload ahci as 
you wish.  :-(

-- 
tejun

Re: Hotplug drives on vt8251 with ahci module

[Mark Lord]

Tejun Heo wrote:
>
> About the disabling on hardreset failure...  Maybe there is some room 
> for improvement - e.g. leave PHY status interrupts alive if it's not 
> causing interrupt storm, but I'm not sure whether the benefits would 
> outweigh the cost.
> 
> Leaving the port frozen (disabled & interrupts plugged) is a safety 
> measure libata implements.  The driver isn't sure in what state the 
> controller and the attached device are in as they are not responding 
> even to the 'hard' reset, so it assumes the worst and shuns the port.
> 
> As I wrote above, you can ask libata to retry by explicitly telling 
> libata to rescan the bus.  I thought that should be enough when I was 

MMm.. sounds like libata should do that periodic polling,
rather than relying on the end-user to do it.  Right?  :)

So the best of both approaches from above:  mask the interrupts
and leave them off, but periodically poll for phy status changes.

??

Re: Hotplug drives on vt8251 with ahci module

[Aalderd Bouwman]

The same turn on/off action with rmmod ahci will work properly I think:
(I have test that action 3 times)

ahci 0000:00:0f.0: version 1.3
ACPI: PCI Interrupt 0000:00:0f.0[B] -> Link [LNKB] -> GSI 10 (level, low) -> 
IRQ 10
ahci 0000:00:0f.0: AHCI 0001.0000 32 slots 4 ports 3 Gbps 0xf impl SATA mode
ahci 0000:00:0f.0: flags: 64bit ncq pm led clo pmp pio slum part
ata13: SATA max UDMA/133 cmd 0xE0486D00 ctl 0x0 bmdma 0x0 irq 10
ata14: SATA max UDMA/133 cmd 0xE0486D80 ctl 0x0 bmdma 0x0 irq 10
ata15: SATA max UDMA/133 cmd 0xE0486E00 ctl 0x0 bmdma 0x0 irq 10
ata16: SATA max UDMA/133 cmd 0xE0486E80 ctl 0x0 bmdma 0x0 irq 10
scsi12 : ahci
ata13: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata13.00: cfg 49:2f00 82:346b 83:7d01 84:4023 85:3469 86:3c01 87:4023 88:407f
ata13.00: ATA-7, max UDMA/133, 156301488 sectors: LBA48 NCQ (depth 0/32)
ata13.00: configured for UDMA/133
scsi13 : ahci
ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata14.00: cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c69 86:3a01 87:4003 88:007f
ata14.00: ATA-7, max UDMA/133, 160086528 sectors: LBA
ata14.00: configured for UDMA/133
scsi14 : ahci
ata15: SATA link down (SStatus 0 SControl 300)
scsi15 : ahci
ata16: SATA link down (SStatus 0 SControl 300)
  Vendor: ATA       Model: ST3808110AS       Rev: 3.AA
  Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
 sda: sda1 sda2 sda3 sda4 < sda5 sda6 >
sd 12:0:0:0: Attached scsi disk sda
sd 12:0:0:0: Attached scsi generic sg0 type 0
  Vendor: ATA       Model: Maxtor 6Y080M0    Rev: YAR5
  Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sdb: 160086528 512-byte hdwr sectors (81964 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 160086528 512-byte hdwr sectors (81964 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
 sdb: sdb1 sdb2
sd 13:0:0:0: Attached scsi disk sdb
sd 13:0:0:0: Attached scsi generic sg1 type 0
ata13: exception Emask 0x10 SAct 0x0 SErr 0x1b0000 action 0x2 frozen
ata13: (irq_stat 0x04400000, PHY RDY changed)
ata14: exception Emask 0x10 SAct 0x0 SErr 0x30000 action 0x2 frozen
ata14: (irq_stat 0x04400000, PHY RDY changed)
ata13: soft resetting port
ata13: SATA link down (SStatus 1 SControl 300)
ata13: failed to recover some devices, retrying in 5 secs
ata14: soft resetting port
ata14: SATA link down (SStatus 1 SControl 300)
ata14: failed to recover some devices, retrying in 5 secs
ata13: hard resetting port
ata13: SATA link down (SStatus 0 SControl 300)
ata13: failed to recover some devices, retrying in 5 secs
ata14: hard resetting port
ata14: SATA link down (SStatus 0 SControl 300)
ata14: failed to recover some devices, retrying in 5 secs
ata13: hard resetting port
ata13: SATA link down (SStatus 0 SControl 300)
ata13.00: disabled
ata13: EH complete
ata13.00: detaching (SCSI 12:0:0:0)
ata14: hard resetting port
ata14: SATA link down (SStatus 0 SControl 300)
ata14.00: disabled
ata14: EH complete
ata14.00: detaching (SCSI 13:0:0:0)
ata13: exception Emask 0x10 SAct 0x0 SErr 0x4070000 action 0x2 frozen
ata13: (irq_stat 0x00400040, connection status changed)
ata13: waiting for device to spin up (8 secs)
ata14: exception Emask 0x10 SAct 0x0 SErr 0x4060000 action 0x2 frozen
ata14: (irq_stat 0x00000040, connection status changed)
ata14: waiting for device to spin up (8 secs)
ata13: soft resetting port
ata13: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata13.00: cfg 49:2f00 82:346b 83:7d01 84:4023 85:3469 86:3c01 87:4023 88:407f
ata13.00: ATA-7, max UDMA/133, 156301488 sectors: LBA48 NCQ (depth 0/32)
ata13.00: configured for UDMA/133
ata13: EH complete
  Vendor: ATA       Model: ST3808110AS       Rev: 3.AA
  Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
 sda: sda1 sda2 sda3 sda4 < sda5 sda6 >
sd 12:0:0:0: Attached scsi disk sda
sd 12:0:0:0: Attached scsi generic sg0 type 0
ata13.00: disabled
ata14: soft resetting port
ata14: port is slow to respond, please be patient
ata14: port failed to respond (30 secs)
ata14: softreset failed (device not ready)
ata14: softreset failed, retrying in 5 secs
ata14: hard resetting port
ata14: port is slow to respond, please be patient
ata14: port failed to respond (30 secs)
ata14: COMRESET failed (device not ready)
ata14: hardreset failed, retrying in 5 secs
ata14: hard resetting port
ata14: port is slow to respond, please be patient
ata14: port failed to respond (30 secs)
ata14: COMRESET failed (device not ready)
ata14: reset failed, giving up
ata14: EH complete
ACPI: PCI interrupt for device 0000:00:0f.0 disabled

As you see the disconnect of a drive is detected.
Is the message: 'failed to recover some devices' correct?
This message apears twice.

Aalderd Bouwman.

On Wednesday 21 June 2006 16:01, Tejun Heo wrote:
> Aalderd Bouwman wrote:
> > Hello,
> >
> > When I load module ahci when a drive is 'online' the drive is can be used
> > normal. When I disconnect the drive EH doesn't recognize that action.
> > When I reconnect the driver posts the following kernel-message:
>
> I'm getting to dislike this via controller.  Again, the controller seems
> to lock up completely on hotplug events.  It might be that the current
> ahci's EH behavior just doesn't fit the via controller as the controller
> seems to lock up similarly in both NCQ and this case.  Maybe it doesn't
> like engine restart sequence (which, BTW, are all done in accordance to
> the AHCI spec).
>
> > Here I disconnect both drives connected to the controller.
> > After the second/third port-reset I also do rmmod ahci:
>
> [--snip--]
>
> > Jun 21 09:15:18 server BUG: unable to handle kernel NULL pointer
> > dereference at virtual address 00000010
> > Jun 21 09:15:18 server printing eip:
> > Jun 21 09:15:18 server e04926cc
> > Jun 21 09:15:18 server *pde = 00000000
> > Jun 21 09:15:18 server Oops: 0000 [#1]
> > Jun 21 09:15:18 server last sysfs file: /block/sdb/sdb2/dev
> > Jun 21 09:15:18 server Modules linked in: ahci libata cls_u32 sch_htb
> > xt_tcpudp iptable_filter iptable_nat ip_tables x_tables ip_nat_irc
> > ip_conntrack_irc ip_nat_ftp ip_nat ip_conntrack_ftp w83627ehf i2c_isa
> > i2c_core 3c59x
> > Jun 21 09:15:18 server CPU:    0
> > Jun 21 09:15:18 server EIP:    0060:[<e04926cc>]    Not tainted VLI
> > Jun 21 09:15:18 server EFLAGS: 00010246   (2.6.17-rc5-mm2 #2)
> > Jun 21 09:15:18 server EIP is at ahci_tf_read+0xa/0x19 [ahci]
> > Jun 21 09:15:18 server eax: 00000000   ebx: e049382f   ecx: de36c29c  
> > edx: 00000000
> > Jun 21 09:15:18 server esi: de36c29c   edi: 00000000   ebp: e0488d00  
> > esp: de43ce84
> > Jun 21 09:15:18 server ds: 007b   es: 007b   ss: 0068
> > Jun 21 09:15:18 server Process scsi_eh_8 (pid: 15546, threadinfo=de43c000
> > task=c66ed550)
> > Jun 21 09:15:18 server Stack: e0492455 de36c29c de43ce94 00000000
> > 0000000a de36c380 00000246 00000046
> > Jun 21 09:15:18 server fffffecc 0000001a de43cecc c0110a49 de43cefc
> > de36c380 de36c29c de36c29c
> > Jun 21 09:15:18 server e04aa50e de36c29c de43cefc e04923f1 e04b0de3
> > de36c29c e04923f1 de43cefc
> > Jun 21 09:15:18 server Call Trace:
> > Jun 21 09:15:18 server <e0492455> ahci_softreset+0x64/0x1d1 [ahci] 
> > <c0110a49> __wake_up+0x14/0x1e
> > Jun 21 09:15:18 server <e04aa50e> ata_do_reset+0x1b/0x4d [libata] 
> > <e04923f1> ahci_softreset+0x0/0x1d1 [ahci]
> > Jun 21 09:15:18 server <e04b0de3> ata_eh_reset+0x78/0xff [libata] 
> > <e04923f1>
>
> But, this is a driver bug.  I tried pretty hard to prevent this from
> happening.  Apparently, I screwed up.  If it's not too much trouble, can
> you please try libata-dev #upstream and see how it works with similar
> unloading scenario.  I'll try to reproduce it here but I wanna know for
> sure that the latest devel tree has the same issue.
>
> Even if you're not familiar w/ git, accessing libata-dev #upstream is
> actually quite simple.
>
> 1. install git (on debian, just install git-core package)
> 2. $ git-clone git://git.kernel.org/pub/scm/linux/kernel/\
>     git/jgarzik/libata-dev.git libata-dev
> 3. $ cd libata-dev
> 4. $ git-checkout -f upstream
> 5. copy over your .config and build.

Re: Hotplug drives on vt8251 with ahci module

[Tejun Heo]

[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

[CC'ing Bastiaan Jacques]

Hello, Aalderd.

Aalderd Bouwman wrote:
> The same turn on/off action with rmmod ahci will work properly I think:
> (I have test that action 3 times)

Great.

> As you see the disconnect of a drive is detected.
> Is the message: 'failed to recover some devices' correct?
> This message apears twice.

AFAICS, libata EH is behaving as expected.  The problem, again, is that 
more often than not, the via controller seems to lock up after certain 
events.  In the message you just posted, ata14 fails to recover after 
power-on.

Hmmm.. Looking at the log, it occurs to me that it might be because the 
controller can't receive D2H FIS after hardreset.  Can you try the 
attached patch?

Bastiaan, I'm shooting in the dark, so please don't hesitate to step in.

-- 
tejun

[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 5033 bytes --]

diff --git a/drivers/scsi/ahci.c b/drivers/scsi/ahci.c
index e261b37..fe12927 100644
--- a/drivers/scsi/ahci.c
+++ b/drivers/scsi/ahci.c
@@ -164,6 +164,7 @@ enum {
 
 	/* ap->flags bits */
 	AHCI_FLAG_RESET_NEEDS_CLO	= (1 << 24),
+	AHCI_FLAG_NO_HRST_D2H_FIS	= (1 << 25),
 };
 
 struct ahci_cmd_hdr {
@@ -277,7 +278,8 @@ static const struct ata_port_info ahci_p
 		.host_flags	= ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
 				  ATA_FLAG_MMIO | ATA_FLAG_PIO_DMA |
 				  ATA_FLAG_SKIP_D2H_BSY |
-				  AHCI_FLAG_RESET_NEEDS_CLO,
+				  AHCI_FLAG_RESET_NEEDS_CLO |
+				  AHCI_FLAG_NO_HRST_D2H_FIS,
 		.pio_mask	= 0x1f, /* pio0-4 */
 		.udma_mask	= 0x7f, /* udma0-6 ; FIXME */
 		.port_ops	= &ahci_ops,
@@ -703,14 +705,18 @@ static int ahci_hardreset(struct ata_por
 	tf.command = 0xff;
 	ata_tf_to_fis(&tf, d2h_fis, 0);
 
-	rc = sata_std_hardreset(ap, class);
-
-	ahci_start_engine(ap);
+	if (!(ap->flags & AHCI_FLAG_NO_HRST_D2H_FIS)) {
+		rc = sata_std_hardreset(ap, class);
+		ahci_start_engine(ap);
 
-	if (rc == 0 && ata_port_online(ap))
-		*class = ahci_dev_classify(ap);
-	if (*class == ATA_DEV_UNKNOWN)
-		*class = ATA_DEV_NONE;
+		if (rc == 0 && ata_port_online(ap))
+			*class = ahci_dev_classify(ap);
+		if (*class == ATA_DEV_UNKNOWN)
+			*class = ATA_DEV_NONE;
+	} else {
+		rc = sata_do_hardreset(ap);
+		ahci_start_engine(ap);
+	}
 
 	DPRINTK("EXIT, rc=%d, class=%u\n", rc, *class);
 	return rc;
diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
index 89c3fbe..9d6ed7e 100644
--- a/drivers/scsi/libata-core.c
+++ b/drivers/scsi/libata-core.c
@@ -2517,6 +2517,46 @@ int sata_phy_resume(struct ata_port *ap,
 	return sata_phy_debounce(ap, params);
 }
 
+int sata_do_hardreset(struct ata_port *ap)
+{
+	u32 scontrol;
+	int rc;
+
+	if (sata_set_spd_needed(ap)) {
+		/* SATA spec says nothing about how to reconfigure
+		 * spd.  To be on the safe side, turn off phy during
+		 * reconfiguration.  This works for at least ICH7 AHCI
+		 * and Sil3124.
+		 */
+		if ((rc = sata_scr_read(ap, SCR_CONTROL, &scontrol)))
+			return rc;
+
+		scontrol = (scontrol & 0x0f0) | 0x302;
+
+		if ((rc = sata_scr_write(ap, SCR_CONTROL, scontrol)))
+			return rc;
+
+		sata_set_spd(ap);
+	}
+
+	/* issue phy wake/reset */
+	if ((rc = sata_scr_read(ap, SCR_CONTROL, &scontrol)))
+		return rc;
+
+	scontrol = (scontrol & 0x0f0) | 0x301;
+
+	if ((rc = sata_scr_write_flush(ap, SCR_CONTROL, scontrol)))
+		return rc;
+
+	/* Couldn't find anything in SATA I/II specs, but AHCI-1.1
+	 * 10.4.2 says at least 1 ms.
+	 */
+	msleep(1);
+
+	/* bring phy back */
+	return sata_phy_resume(ap, sata_deb_timing_eh);
+}
+
 static void ata_wait_spinup(struct ata_port *ap)
 {
 	struct ata_eh_context *ehc = &ap->eh_context;
@@ -2670,44 +2710,16 @@ int ata_std_softreset(struct ata_port *a
  */
 int sata_std_hardreset(struct ata_port *ap, unsigned int *class)
 {
-	u32 scontrol;
 	int rc;
 
 	DPRINTK("ENTER\n");
 
-	if (sata_set_spd_needed(ap)) {
-		/* SATA spec says nothing about how to reconfigure
-		 * spd.  To be on the safe side, turn off phy during
-		 * reconfiguration.  This works for at least ICH7 AHCI
-		 * and Sil3124.
-		 */
-		if ((rc = sata_scr_read(ap, SCR_CONTROL, &scontrol)))
-			return rc;
-
-		scontrol = (scontrol & 0x0f0) | 0x302;
-
-		if ((rc = sata_scr_write(ap, SCR_CONTROL, scontrol)))
-			return rc;
-
-		sata_set_spd(ap);
-	}
-
-	/* issue phy wake/reset */
-	if ((rc = sata_scr_read(ap, SCR_CONTROL, &scontrol)))
-		return rc;
-
-	scontrol = (scontrol & 0x0f0) | 0x301;
-
-	if ((rc = sata_scr_write_flush(ap, SCR_CONTROL, scontrol)))
+	/* reset the phy */
+	rc = sata_do_hardreset(ap);
+	if (rc) {
+		ata_port_printk(ap, KERN_ERR, "COMRESET failed (%d)\n", rc);
 		return rc;
-
-	/* Couldn't find anything in SATA I/II specs, but AHCI-1.1
-	 * 10.4.2 says at least 1 ms.
-	 */
-	msleep(1);
-
-	/* bring phy back */
-	sata_phy_resume(ap, sata_deb_timing_eh);
+	}
 
 	/* TODO: phy layer with polling, timeouts, etc. */
 	if (ata_port_offline(ap)) {
@@ -5833,6 +5845,7 @@ EXPORT_SYMBOL_GPL(sata_phy_resume);
 EXPORT_SYMBOL_GPL(sata_phy_reset);
 EXPORT_SYMBOL_GPL(__sata_phy_reset);
 EXPORT_SYMBOL_GPL(ata_bus_reset);
+EXPORT_SYMBOL_GPL(sata_do_hardreset);
 EXPORT_SYMBOL_GPL(ata_std_prereset);
 EXPORT_SYMBOL_GPL(ata_std_softreset);
 EXPORT_SYMBOL_GPL(sata_std_hardreset);
diff --git a/include/linux/libata.h b/include/linux/libata.h
index 6b3c3af..533ed44 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -631,6 +631,7 @@ extern void ata_bus_reset(struct ata_por
 extern int sata_set_spd(struct ata_port *ap);
 extern int sata_phy_debounce(struct ata_port *ap, const unsigned long *param);
 extern int sata_phy_resume(struct ata_port *ap, const unsigned long *param);
+extern int sata_do_hardreset(struct ata_port *ap);
 extern int ata_std_prereset(struct ata_port *ap);
 extern int ata_std_softreset(struct ata_port *ap, unsigned int *classes);
 extern int sata_std_hardreset(struct ata_port *ap, unsigned int *class);
diff --git a/patches/series b/patches/series
index 9415c25..84b70e4 100644

Re: Hotplug drives on vt8251 with ahci module

[Tejun Heo]

Tejun Heo wrote:
[--snip--]
> Bastiaan, I'm shooting in the dark, so please don't hesitate to step in.

Bastiaan, it also seems that AHCI_FLAG_RESET_NEEDS_CLO workaround is not 
necessary anymore after hotplug changes which added 
ATA_FLAG_SKIP_D2H_BSY.  Can you please verify this?

Thanks.

-- 
tejun

Re: Hotplug drives on vt8251 with ahci module

[Tejun Heo]

[CC'ing Jeff. Hi!]

Mark Lord wrote:
> Tejun Heo wrote:
>>
>> About the disabling on hardreset failure...  Maybe there is some room 
>> for improvement - e.g. leave PHY status interrupts alive if it's not 
>> causing interrupt storm, but I'm not sure whether the benefits would 
>> outweigh the cost.
>>
>> Leaving the port frozen (disabled & interrupts plugged) is a safety 
>> measure libata implements.  The driver isn't sure in what state the 
>> controller and the attached device are in as they are not responding 
>> even to the 'hard' reset, so it assumes the worst and shuns the port.
>>
>> As I wrote above, you can ask libata to retry by explicitly telling 
>> libata to rescan the bus.  I thought that should be enough when I was 
> 
> MMm.. sounds like libata should do that periodic polling,
> rather than relying on the end-user to do it.  Right?  :)
> 
> So the best of both approaches from above:  mask the interrupts
> and leave them off, but periodically poll for phy status changes.

Hmm... Polling.  Yeap, that's certainly a possibility.  It's definitely 
better than selectively enabling PHY status change IRQ.  Also, we can 
use the same facility to implement hotplug for ports which have SStatus 
but no PHY status changed IRQ.  PMP requires command issuance for 
SStatus polling but PMP gets detached when a port gets frozen & 
disabled, so it doesn't matter anyway.  I'll put this on my to-do list. 
  Thanks for the suggestion.

-- 
tejun

Re: Hotplug drives on vt8251 with ahci module

[Aalderd Bouwman]

The dmesg will say enough I think:

libata version 1.30 loaded.
ahci 0000:00:0f.0: version 1.3
ACPI: PCI Interrupt 0000:00:0f.0[B] -> Link [LNKB] -> GSI 10 (level,
low) -> IRQ 10
ahci 0000:00:0f.0: AHCI 0001.0000 32 slots 4 ports 3 Gbps 0xf impl SATA
mode
ahci 0000:00:0f.0: flags: 64bit ncq pm led clo pmp pio slum part
ata1: SATA max UDMA/133 cmd 0xE0488D00 ctl 0x0 bmdma 0x0 irq 10
ata2: SATA max UDMA/133 cmd 0xE0488D80 ctl 0x0 bmdma 0x0 irq 10
ata3: SATA max UDMA/133 cmd 0xE0488E00 ctl 0x0 bmdma 0x0 irq 10
ata4: SATA max UDMA/133 cmd 0xE0488E80 ctl 0x0 bmdma 0x0 irq 10
scsi0 : ahci
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: configured for UDMA/133
scsi1 : ahci
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata2.00: configured for UDMA/133
scsi2 : ahci
ata3: SATA link down (SStatus 0 SControl 300)
scsi3 : ahci
ata4: SATA link down (SStatus 0 SControl 300)
  Vendor: ATA       Model: ST3808110AS       Rev: 3.AA
  Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
 sda: sda1 sda2 sda3 sda4 < sda5 sda6 >
sd 0:0:0:0: Attached scsi disk sda
sd 0:0:0:0: Attached scsi generic sg0 type 0
  Vendor: ATA       Model: Maxtor 6Y080M0    Rev: YAR5
  Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sdb: 160086528 512-byte hdwr sectors (81964 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 160086528 512-byte hdwr sectors (81964 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
 sdb: sdb1 sdb2
sd 1:0:0:0: Attached scsi disk sdb
sd 1:0:0:0: Attached scsi generic sg1 type 0
ReiserFS: sda5: found reiserfs format "3.6" with standard journal
ReiserFS: sda5: using ordered data mode
ReiserFS: sda5: journal params: device sda5, size 8192, journal first
block 18, max trans len 1024, max batch 900, max commit age 30, max
trans age 30
ReiserFS: sda5: checking transaction log (sda5)
ReiserFS: sda5: Using r5 hash to sort names
ReiserFS: sdb1: found reiserfs format "3.6" with standard journal
ReiserFS: sdb1: using ordered data mode
ReiserFS: sdb1: journal params: device sdb1, size 8192, journal first
block 18, max trans len 1024, max batch 900, max commit age 30, max
trans age 30
ReiserFS: sdb1: checking transaction log (sdb1)
ReiserFS: sdb1: Using r5 hash to sort names
ata2: exception Emask 0x10 SAct 0x0 SErr 0x30000 action 0x2 frozen
ata2: (irq_stat 0x04400000, PHY RDY changed)
ata2: soft resetting port
ata2: SATA link down (SStatus 1 SControl 300)
ata2: failed to recover some devices, retrying in 5 secs
ata2: hard resetting port
ata2: SATA link down (SStatus 0 SControl 300)
ata2: failed to recover some devices, retrying in 5 secs
ata2: hard resetting port
ata2: SATA link down (SStatus 0 SControl 300)
ata2.00: disabled
ata2: EH complete
ata2.00: detaching (SCSI 1:0:0:0)
ata2: exception Emask 0x10 SAct 0x0 SErr 0x4060000 action 0x2 frozen
ata2: (irq_stat 0x00000040, connection status changed)
ata2: waiting for device to spin up (8 secs)
ata2: soft resetting port
ata2: port is slow to respond, please be patient
ata2: port failed to respond (30 secs)
ata2: softreset failed (device not ready)
ata2: softreset failed, retrying in 5 secs
ata2: hard resetting port
ata2: port is slow to respond, please be patient
ata2: port failed to respond (30 secs)
ata2: softreset failed (device not ready)
ata2: follow-up softreset failed, retrying in 5 secs
ata2: hard resetting port
ata2: port is slow to respond, please be patient
ata2: port failed to respond (30 secs)
ata2: softreset failed (device not ready)
ata2: reset failed, giving up
ata2: EH complete
ata1.00: disabled
ACPI: PCI interrupt for device 0000:00:0f.0 disabled

Aalderd.

On Fri, 2006-06-23 at 12:52 +0900, Tejun Heo wrote:
> [CC'ing Bastiaan Jacques]
> 
> Hello, Aalderd.
> 
> Aalderd Bouwman wrote:
> > The same turn on/off action with rmmod ahci will work properly I think:
> > (I have test that action 3 times)
> 
> Great.
> 
> > As you see the disconnect of a drive is detected.
> > Is the message: 'failed to recover some devices' correct?
> > This message apears twice.
> 
> AFAICS, libata EH is behaving as expected.  The problem, again, is that 
> more often than not, the via controller seems to lock up after certain 
> events.  In the message you just posted, ata14 fails to recover after 
> power-on.
> 
> Hmmm.. Looking at the log, it occurs to me that it might be because the 
> controller can't receive D2H FIS after hardreset.  Can you try the 
> attached patch?
> 
> Bastiaan, I'm shooting in the dark, so please don't hesitate to step in.
> 
> plain text document attachment (patch)
> diff --git a/drivers/scsi/ahci.c b/drivers/scsi/ahci.c
> index e261b37..fe12927 100644
> --- a/drivers/scsi/ahci.c
> +++ b/drivers/scsi/ahci.c
> @@ -164,6 +164,7 @@ enum {
>  
>  	/* ap->flags bits */
>  	AHCI_FLAG_RESET_NEEDS_CLO	= (1 << 24),
> +	AHCI_FLAG_NO_HRST_D2H_FIS	= (1 << 25),
>  };
>  
>  struct ahci_cmd_hdr {
> @@ -277,7 +278,8 @@ static const struct ata_port_info ahci_p
>  		.host_flags	= ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
>  				  ATA_FLAG_MMIO | ATA_FLAG_PIO_DMA |
>  				  ATA_FLAG_SKIP_D2H_BSY |
> -				  AHCI_FLAG_RESET_NEEDS_CLO,
> +				  AHCI_FLAG_RESET_NEEDS_CLO |
> +				  AHCI_FLAG_NO_HRST_D2H_FIS,
>  		.pio_mask	= 0x1f, /* pio0-4 */
>  		.udma_mask	= 0x7f, /* udma0-6 ; FIXME */
>  		.port_ops	= &ahci_ops,
> @@ -703,14 +705,18 @@ static int ahci_hardreset(struct ata_por
>  	tf.command = 0xff;
>  	ata_tf_to_fis(&tf, d2h_fis, 0);
>  
> -	rc = sata_std_hardreset(ap, class);
> -
> -	ahci_start_engine(ap);
> +	if (!(ap->flags & AHCI_FLAG_NO_HRST_D2H_FIS)) {
> +		rc = sata_std_hardreset(ap, class);
> +		ahci_start_engine(ap);
>  
> -	if (rc == 0 && ata_port_online(ap))
> -		*class = ahci_dev_classify(ap);
> -	if (*class == ATA_DEV_UNKNOWN)
> -		*class = ATA_DEV_NONE;
> +		if (rc == 0 && ata_port_online(ap))
> +			*class = ahci_dev_classify(ap);
> +		if (*class == ATA_DEV_UNKNOWN)
> +			*class = ATA_DEV_NONE;
> +	} else {
> +		rc = sata_do_hardreset(ap);
> +		ahci_start_engine(ap);
> +	}
>  
>  	DPRINTK("EXIT, rc=%d, class=%u\n", rc, *class);
>  	return rc;
> diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
> index 89c3fbe..9d6ed7e 100644
> --- a/drivers/scsi/libata-core.c
> +++ b/drivers/scsi/libata-core.c
> @@ -2517,6 +2517,46 @@ int sata_phy_resume(struct ata_port *ap,
>  	return sata_phy_debounce(ap, params);
>  }
>  
> +int sata_do_hardreset(struct ata_port *ap)
> +{
> +	u32 scontrol;
> +	int rc;
> +
> +	if (sata_set_spd_needed(ap)) {
> +		/* SATA spec says nothing about how to reconfigure
> +		 * spd.  To be on the safe side, turn off phy during
> +		 * reconfiguration.  This works for at least ICH7 AHCI
> +		 * and Sil3124.
> +		 */
> +		if ((rc = sata_scr_read(ap, SCR_CONTROL, &scontrol)))
> +			return rc;
> +
> +		scontrol = (scontrol & 0x0f0) | 0x302;
> +
> +		if ((rc = sata_scr_write(ap, SCR_CONTROL, scontrol)))
> +			return rc;
> +
> +		sata_set_spd(ap);
> +	}
> +
> +	/* issue phy wake/reset */
> +	if ((rc = sata_scr_read(ap, SCR_CONTROL, &scontrol)))
> +		return rc;
> +
> +	scontrol = (scontrol & 0x0f0) | 0x301;
> +
> +	if ((rc = sata_scr_write_flush(ap, SCR_CONTROL, scontrol)))
> +		return rc;
> +
> +	/* Couldn't find anything in SATA I/II specs, but AHCI-1.1
> +	 * 10.4.2 says at least 1 ms.
> +	 */
> +	msleep(1);
> +
> +	/* bring phy back */
> +	return sata_phy_resume(ap, sata_deb_timing_eh);
> +}
> +
>  static void ata_wait_spinup(struct ata_port *ap)
>  {
>  	struct ata_eh_context *ehc = &ap->eh_context;
> @@ -2670,44 +2710,16 @@ int ata_std_softreset(struct ata_port *a
>   */
>  int sata_std_hardreset(struct ata_port *ap, unsigned int *class)
>  {
> -	u32 scontrol;
>  	int rc;
>  
>  	DPRINTK("ENTER\n");
>  
> -	if (sata_set_spd_needed(ap)) {
> -		/* SATA spec says nothing about how to reconfigure
> -		 * spd.  To be on the safe side, turn off phy during
> -		 * reconfiguration.  This works for at least ICH7 AHCI
> -		 * and Sil3124.
> -		 */
> -		if ((rc = sata_scr_read(ap, SCR_CONTROL, &scontrol)))
> -			return rc;
> -
> -		scontrol = (scontrol & 0x0f0) | 0x302;
> -
> -		if ((rc = sata_scr_write(ap, SCR_CONTROL, scontrol)))
> -			return rc;
> -
> -		sata_set_spd(ap);
> -	}
> -
> -	/* issue phy wake/reset */
> -	if ((rc = sata_scr_read(ap, SCR_CONTROL, &scontrol)))
> -		return rc;
> -
> -	scontrol = (scontrol & 0x0f0) | 0x301;
> -
> -	if ((rc = sata_scr_write_flush(ap, SCR_CONTROL, scontrol)))
> +	/* reset the phy */
> +	rc = sata_do_hardreset(ap);
> +	if (rc) {
> +		ata_port_printk(ap, KERN_ERR, "COMRESET failed (%d)\n", rc);
>  		return rc;
> -
> -	/* Couldn't find anything in SATA I/II specs, but AHCI-1.1
> -	 * 10.4.2 says at least 1 ms.
> -	 */
> -	msleep(1);
> -
> -	/* bring phy back */
> -	sata_phy_resume(ap, sata_deb_timing_eh);
> +	}
>  
>  	/* TODO: phy layer with polling, timeouts, etc. */
>  	if (ata_port_offline(ap)) {
> @@ -5833,6 +5845,7 @@ EXPORT_SYMBOL_GPL(sata_phy_resume);
>  EXPORT_SYMBOL_GPL(sata_phy_reset);
>  EXPORT_SYMBOL_GPL(__sata_phy_reset);
>  EXPORT_SYMBOL_GPL(ata_bus_reset);
> +EXPORT_SYMBOL_GPL(sata_do_hardreset);
>  EXPORT_SYMBOL_GPL(ata_std_prereset);
>  EXPORT_SYMBOL_GPL(ata_std_softreset);
>  EXPORT_SYMBOL_GPL(sata_std_hardreset);
> diff --git a/include/linux/libata.h b/include/linux/libata.h
> index 6b3c3af..533ed44 100644
> --- a/include/linux/libata.h
> +++ b/include/linux/libata.h
> @@ -631,6 +631,7 @@ extern void ata_bus_reset(struct ata_por
>  extern int sata_set_spd(struct ata_port *ap);
>  extern int sata_phy_debounce(struct ata_port *ap, const unsigned long *param);
>  extern int sata_phy_resume(struct ata_port *ap, const unsigned long *param);
> +extern int sata_do_hardreset(struct ata_port *ap);
>  extern int ata_std_prereset(struct ata_port *ap);
>  extern int ata_std_softreset(struct ata_port *ap, unsigned int *classes);
>  extern int sata_std_hardreset(struct ata_port *ap, unsigned int *class);
> diff --git a/patches/series b/patches/series
> index 9415c25..84b70e4 100644