Skip to contentSkip to conversation

New: sata_nv hotplug not work in 2.6.27.10

Bugme-new Andrew Morton 5 participants 9 messages Jan 5, 2009 – Feb 3, 2009 1 message not in the archive libata

lore
Share & tools
lore

Andrew Morton

author
#1 lore raw
In reply to a message not in the archive

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 17 lines · On Sat, 3 Jan 2009 13:12:09 -0800 (PST) [email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=12351

Summary: sata_nv hotplug not work in 2.6.27.10
Product: IO/Storage
Version: 2.5
KernelVersion: 2.6.27.10
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Serial ATA
AssignedTo: [email protected]
ReportedBy: [email protected]

Quoted 2 lines

Latest working kernel version:2.6.27
Earliest failing kernel version:2.6.27.10

A regression in -stable.

Quoted 55 lines

Hardware Environment:x86 ASUS M2N-E
Problem Description: sata_nv hotplug dont work in 2.6.27.10

Steps to reproduce:

when I hotplug my sata disk dmesg say:

- kernel 2.6.27:

ta2: exception Emask 0x10 SAct 0x0 SErr 0x50000 action 0xe frozen
ata2: SError: { PHYRdyChg CommWake }
ata2: hard resetting link
ata2: link is slow to respond, please be patient (ready=-19)
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata2.00: ATA-7: ST3320620AS, 3.AAJ, max UDMA/133
ata2.00: 625142448 sectors, multi 0: LBA48 NCQ (depth 31/32) ata2.00: configured for UDMA/133
ata2: EH complete
scsi 1:0:0:0: Direct-Access ATA ST3320620AS 3.AA PQ: 0 ANSI: 5
sd 1:0:0:0: [sdb] 625142448 512-byte hardware sectors (320073 MB) sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 1:0:0:0: [sdb] 625142448 512-byte hardware sectors (320073 MB) sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sdb: sdb1 sdb2 < sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 sdb11 sdb12 sdb13 sdb14 sdb15

Quoted 1 line

sd 1:0:0:0: [sdb] Attached SCSI disk

- kernel 2.6.27.10:

ata2: exception Emask 0x10 SAct 0x0 SErr 0x150000 action 0xe frozen
ata2: SError: { PHYRdyChg CommWake Dispar }
ata2: link is slow to respond, please be patient (ready=0)
ata2: device not ready (errno=-16), forcing hardreset
ata2: soft resetting link
ata2: link is slow to respond, please be patient (ready=0)
ata2: SRST failed (errno=-16)
ata2: soft resetting link
ata2: link is slow to respond, please be patient (ready=0)
ata2: SRST failed (errno=-16)
ata2: soft resetting link
ata2: link is slow to respond, please be patient (ready=0)
ata2: SRST failed (errno=-16)
ata2: limiting SATA link speed to 1.5 Gbps
ata2: soft resetting link
ata2: SRST failed (errno=-16)
ata2: reset failed, giving up
ata2: EH complete

#2 lore raw

(CCing Tejun)

Quoted 23 lines · Andrew Morton

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 17 lines · On Sat, 3 Jan 2009 13:12:09 -0800 (PST) [email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=12351

Summary: sata_nv hotplug not work in 2.6.27.10
Product: IO/Storage
Version: 2.5
KernelVersion: 2.6.27.10
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Serial ATA
AssignedTo: [email protected]
ReportedBy: [email protected]

Quoted 4 lines
Quoted 2 lines

Latest working kernel version:2.6.27
Earliest failing kernel version:2.6.27.10

A regression in -stable.

Does reverting this patch help?

http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-allstable.git;a=commit;h=814eb57e1799337d9fbb68f5d838afa507dc014e

Quoted 2 lines
Quoted 2 lines

Hardware Environment:x86 ASUS M2N-E

OK, this is an MCP61 board. We're now using softreset instead of hardreset on hotplug and apparently that doesn't work. Thing is that:

http://bugzilla.kernel.org/show_bug.cgi?id=11195

reported that hardreset was borked on that controller. Seems kind of contradictory..

/if only NVidia could be consistent in its hardware bugs..

Quoted 59 lines
Quoted 44 lines

Problem Description: sata_nv hotplug dont work in 2.6.27.10

Steps to reproduce:

when I hotplug my sata disk dmesg say:

- kernel 2.6.27:

ta2: exception Emask 0x10 SAct 0x0 SErr 0x50000 action 0xe frozen
ata2: SError: { PHYRdyChg CommWake }
ata2: hard resetting link
ata2: link is slow to respond, please be patient (ready=-19)
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata2.00: ATA-7: ST3320620AS, 3.AAJ, max UDMA/133
ata2.00: 625142448 sectors, multi 0: LBA48 NCQ (depth 31/32) ata2.00: configured for UDMA/133
ata2: EH complete
scsi 1:0:0:0: Direct-Access ATA ST3320620AS 3.AA PQ: 0 ANSI: 5
sd 1:0:0:0: [sdb] 625142448 512-byte hardware sectors (320073 MB) sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 1:0:0:0: [sdb] 625142448 512-byte hardware sectors (320073 MB) sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sdb: sdb1 sdb2 < sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 sdb11 sdb12 sdb13 sdb14 sdb15
sd 1:0:0:0: [sdb] Attached SCSI disk

- kernel 2.6.27.10:

ata2: exception Emask 0x10 SAct 0x0 SErr 0x150000 action 0xe frozen
ata2: SError: { PHYRdyChg CommWake Dispar }
ata2: link is slow to respond, please be patient (ready=0)
ata2: device not ready (errno=-16), forcing hardreset
ata2: soft resetting link
ata2: link is slow to respond, please be patient (ready=0)
ata2: SRST failed (errno=-16)
ata2: soft resetting link
ata2: link is slow to respond, please be patient (ready=0)
ata2: SRST failed (errno=-16)

Quoted 9 lines

ata2: soft resetting link
ata2: link is slow to respond, please be patient (ready=0)
ata2: SRST failed (errno=-16)
ata2: limiting SATA link speed to 1.5 Gbps
ata2: soft resetting link
ata2: SRST failed (errno=-16)
ata2: reset failed, giving up
ata2: EH complete

--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#3 lore raw
Quoted 4 lines · Robert Hancock
Quoted 1 line
Quoted 1 line

Hardware Environment:x86 ASUS M2N-E

OK, this is an MCP61 board. We're now using softreset instead of hardreset on hotplug and apparently that doesn't work. Thing is that:

no, it is not MCP61, but MCP55:

dual ~ # lspci
00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a1) 00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a2) 00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a2) 00:02.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1) 00:02.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2) 00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1) 00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2)

dual ~ # dmidecode

# dmidecode 2.9
SMBIOS 2.4 present.
72 structures occupying 2069 bytes.
Table at 0x000F0000.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: Phoenix Technologies, LTD
Version: ASUS M2N-E ACPI BIOS Revision 1601

#4 lore raw
Quoted 6 lines · Giovanni Pancotti
Quoted 2 lines · Robert Hancock
Quoted 1 line
Quoted 1 line

Hardware Environment:x86 ASUS M2N-E

OK, this is an MCP61 board. We're now using softreset instead of hardreset on hotplug and apparently that doesn't work. Thing is that:

no, it is not MCP61, but MCP55:

Ahh, ok, that is less contradictory then :-) Presumably we should still be using hardreset on that chipset.

Quoted 22 lines

dual ~ # lspci
00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a1) 00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a2) 00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a2) 00:02.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1) 00:02.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2) 00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1) 00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2)

dual ~ # dmidecode

# dmidecode 2.9
SMBIOS 2.4 present.
72 structures occupying 2069 bytes.
Table at 0x000F0000.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: Phoenix Technologies, LTD
Version: ASUS M2N-E ACPI BIOS Revision 1601

#5 lore raw
Quoted 11 lines · Robert Hancock
Quoted 7 lines · Giovanni Pancotti
Quoted 3 lines · Robert Hancock
Quoted 1 line
Quoted 1 line

Hardware Environment:x86 ASUS M2N-E

OK, this is an MCP61 board. We're now using softreset instead of hardreset on hotplug and apparently that doesn't work. Thing is that:

no, it is not MCP61, but MCP55:

Ahh, ok, that is less contradictory then :-) Presumably we should still be using hardreset on that chipset.

So, do we know how to solve this in the 2.6.27.y tree?

thanks,

greg k-h

#6 lore raw
Quoted 10 lines · Greg KH
Quoted 7 lines · Robert Hancock
Quoted 5 lines · Giovanni Pancotti
Quoted 2 lines · Robert Hancock
Quoted 1 line
Quoted 1 line

Hardware Environment:x86 ASUS M2N-E

OK, this is an MCP61 board. We're now using softreset instead of hardreset on hotplug and apparently that doesn't work. Thing is that:

no, it is not MCP61, but MCP55:

Ahh, ok, that is less contradictory then :-) Presumably we should still be using hardreset on that chipset.

So, do we know how to solve this in the 2.6.27.y tree?

Can you try reverting this patch?

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=3c324283e6cdb79210cf7975c3e40d3ba3e672b2

This likely isn't a proper fix as it will probably re-break some other chipsets but it will confirm what the problem is in this case. It looks like this patch changed MCP55 to inherit from generic_ops instead of common_ops which caused it to use soft reset instead of hard reset. Not sure if that was intentional or not.. Tejun?

We really ought to fix up some of the naming in this driver to be less confusing. Especially the "generic" stuff should be renamed, it's not generic at all (it seems to only apply to MCP61 currently) yet it's used as a base operations for other chipset types.

#7 lore raw
Quoted 16 lines · Robert Hancock
Quoted 4 lines · Greg KH
Quoted 3 lines · Robert Hancock
Quoted 2 lines · Giovanni Pancotti

On Monday 05 January 2009, alle 18:57, Robert Hancock wrote:

Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line

Hardware Environment:x86 ASUS M2N-E

OK, this is an MCP61 board. We're now using softreset instead of hardreset on hotplug and apparently that doesn't work. Thing is that:

no, it is not MCP61, but MCP55:

Ahh, ok, that is less contradictory then :-) Presumably we should still be using hardreset on that chipset.

So, do we know how to solve this in the 2.6.27.y tree?

Can you try reverting this patch?

Quoted 7 lines

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=3c324283e6cdb79210cf7975c3e40d3ba3e672b2

This likely isn't a proper fix as it will probably re-break some other chipsets but it will confirm what the problem is in this case. It looks like this patch changed MCP55 to inherit from generic_ops instead of common_ops which caused it to use soft reset instead of hard reset. Not sure if that was intentional or not.. Tejun?

I don't want to revert that, as I don't want to break anything else :)

thanks,

greg k-h

#8 lore raw
Quoted 10 lines · Greg KH
Quoted 9 lines · Robert Hancock
Quoted 8 lines · Greg KH
Quoted 7 lines · Robert Hancock
Quoted 5 lines · Giovanni Pancotti
Quoted 2 lines · Robert Hancock
Quoted 1 line
Quoted 1 line

Hardware Environment:x86 ASUS M2N-E

OK, this is an MCP61 board. We're now using softreset instead of hardreset on hotplug and apparently that doesn't work. Thing is that:

no, it is not MCP61, but MCP55:

Ahh, ok, that is less contradictory then :-) Presumably we should still be using hardreset on that chipset.

Quoted 8 lines
Quoted 6 lines
Quoted 1 line

So, do we know how to solve this in the 2.6.27.y tree?

Can you try reverting this patch?

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=3c324283e6cdb79210cf7975c3e40d3ba3e672b2

This likely isn't a proper fix as it will probably re-break some other chipsets but it will confirm what the problem is in this case. It looks like this patch changed MCP55 to inherit from generic_ops instead of common_ops which caused it to use soft reset instead of hard reset. Not sure if that was intentional or not.. Tejun?

I don't want to revert that, as I don't want to break anything else :)

That was directed at the reporter :-) However, hopefully this patch in current git will resolve the problem:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2d775708bc6613f1be47f1e720781343341ecc94

#9 lore raw
Quoted 23 lines · Robert Hancock
Quoted 22 lines · Greg KH
Quoted 21 lines · Robert Hancock
Quoted 11 lines · Greg KH
Quoted 9 lines · Robert Hancock
Quoted 6 lines · Giovanni Pancotti
Quoted 3 lines · Robert Hancock
Quoted 1 line
Quoted 1 line

Hardware Environment:x86 ASUS M2N-E

OK, this is an MCP61 board. We're now using softreset instead of hardreset on hotplug and apparently that doesn't work. Thing is that:

no, it is not MCP61, but MCP55:

Ahh, ok, that is less contradictory then :-) Presumably we should still be using hardreset on that chipset.

So, do we know how to solve this in the 2.6.27.y tree?

Can you try reverting this patch?

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=3c324283e6cdb79210cf7975c3e40d3ba3e672b2

This likely isn't a proper fix as it will probably re-break some other chipsets but it will confirm what the problem is in this case. It looks like this patch changed MCP55 to inherit from generic_ops instead of common_ops which caused it to use soft reset instead of hard reset. Not sure if that was intentional or not.. Tejun?

Quoted 6 lines
Quoted 1 line

I don't want to revert that, as I don't want to break anything else :)

That was directed at the reporter :-) However, hopefully this patch in current git will resolve the problem:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2d775708bc6613f1be47f1e720781343341ecc94

Ah nice, I'll queue that one up as well :)

thanks,

greg k-h