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
-
: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
