Bug 48631
| Summary: | [Regression] SATA reset failing in 3.6 | ||
|---|---|---|---|
| Product: | IO/Storage | Reporter: | Eugene (ken20001) |
| Component: | Serial ATA | Assignee: | Aaron Lu (aaron.lu) |
| Status: | CLOSED INVALID | ||
| Severity: | high | CC: | aaron.lu, alan, fis, russianneuromancer |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | Subsystem: | ||
| Regression: | Yes | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 56331 | ||
| Attachments: |
lspci
dmesg with kernel 3.5.0-17 dmesg with Linux 3.5 dmesg from fail kernel 3.6 boot |
||
|
Description
Eugene
2012-10-09 10:27:31 UTC
Created attachment 82711 [details]
dmesg with kernel 3.5.0-17
Same issue with JMB368 IDE-controller. With Linux 3.5 system boot fine. Do I need to provide additional information? Can you attach a dmesg as well.. looks like 3.6 broke the Jmicron controllers. Created attachment 83051 [details]
dmesg with Linux 3.5
Sure.
Do you need some more info or it is enough to start fixing the bug ? Bugzilla is just used to track bugs not fix them. Thats a question to direct to your distribution. Discussing it on linux-ata@vger.kernel.org may also find folks interested in it. I just ment do you need any additional info to change status? Cause it's still NEEDINFO. Just this. And, BTW, should I also write the same report on launchpad or somwhere else to make start fixing this bug ? I'm not sure what the Ubuntu procedure for bug fixing is sorry Added Aaron Lu to CC, as he has been poking at libata ACPI lately. Hello Eugene, Can you please check in 3.5, which kernel module is driving your JMicron controller? And also, in the failed 3.6 kernel, can you show more dmesg so that I can see which kernel module is initializing the controller. And you can also try to blacklist pata_acpi to see if this makes a difference, thanks. Err...Just saw in dmesg it is pata_jmicron in 3.5 that is driving the JMicron controller. So my guess is that, due to a latent pata_acpi bug fixed, pata_acpi is now driving the controller but pre_reset failed. Please blacklist pata_acpi to see if this is the case, thanks. Recently tried blacklist pata_acpi in /etc/modprobe.d/blacklist-jmicron_module.conf Nothing changed for Kernel 3.6. Created attachment 87321 [details]
dmesg from fail kernel 3.6 boot
I've got dmesg after trying to boot with blacklisted module pata_acpi. See the attachment. >dmesg from fail kernel 3.5 boot
Sorry, from kernel 3.6.
Hello Eugene, The dmesg shows that for the failed ata controller channel(ata7 and ata8), it is still pata_acpi being used: [ 2.238918] pata_acpi 0000:03:00.1: setting latency timer to 64 [ 2.239727] scsi6 : pata_acpi [ 2.239937] scsi7 : pata_acpi [ 2.240128] ata7: PATA max UDMA/133 cmd 0xdc00 ctl 0xd880 bmdma 0xd400 irq 17 [ 2.240130] ata8: PATA max UDMA/133 cmd 0xd800 ctl 0xd480 bmdma 0xd408 irq 17 So the problem is still there. You may need to try another way to blacklist it. >You may need to try another way to blacklist it.
Any suggestions how to do it ?
I don't know how to blacklist pata_acpi. I try it like noted in http://wiki.debian.org/KernelModuleBlacklisting but it is still loading during boot. Also I've tried LiveCD with kernel 3.6 and lsmod is not shows pata_acpi at all. Hello Eugene, Just installed a Ubuntu 12.10 vm and saw that the PATA_ACPI is built into the kernel by default, so I'm afraid you have no way of blacklisting it. You can try re-compiling the kernel and make sure the CONFIG_PATA_ACPI option is unset to see the result, if this is possible for you. And you are advised to write to Ubuntu kernel team to suggest them not built in the PATA_ACPI module by default. They need to include it for some systems. They need to ensure they either - build in all the ATA drivers (in which case it is tried last) or - build the pata_acpi driver modular and load it last > You can try re-compiling the kernel and make sure the CONFIG_PATA_ACPI option
> is unset to see the result, if this is possible for you.
Sorry, I'm not familiar with kernel compilation stuff. We're already know - this controller is driven dy different kernel module since 3.6 kernel module, and make system not possible to boot, if system disk attached to this controller. Is ti possible for you to somehow fix problem on kernel side and make kernel use pata_jmicron for JMicron controllers again?
It doesn't look like a kernel change. It appears at this point to be a mistake by your distribution so it needs to go back to the distribution maintainers. I agree with Alan. Eugene, Please talk to the distribution maintainer to let them make sure pata_acpi should be the last one to drive the controller. Then please continue the discussion in the lauchpad bug page with the information you got from here. And once it is confirmed that the problem can be solved, we can close the bug, thanks. Assign it to me to close it, since it is not a kernel bug. (In reply to comment #22) > It doesn't look like a kernel change. It appears at this point to be a > mistake > by your distribution so it needs to go back to the distribution maintainers. Actually, although this might be a distro error, this was done by a kernel change, specifically 30dcf76acc (I was tracing the same bug with different driver and bisected to this). There is some progress in Ubuntu bugreport: https://bugs.launchpad.net/bugs/1084783 |