[PATCH 0/4]: Resolve MSI vs. INTX_DISABLE quirks, V2.

[PATCH 0/4]: Resolve MSI vs. INTX_DISABLE quirks, V2.

[David Miller]

Ok, I've respun the patches including all of the feedback I've
obtained.  Again, it's at:

	kernel.org:/pub/scm/linux/kernel/git/davem/msiquirk-2.6.git

Greg, I think this stuff is ready to go so if you would pull
them in I would really appreciate it.

These changes clean up the handling of the common quirk wherein
setting INTX_DISABLE will mistakedly disable MSI generation for some
devices.

For devices without that problem, we want to keep the pci_intx() calls
in drivers/pci/msi.c because those help protect against devices with
the opposite problem.  Such devices always generate INTX interrupts
even when MSI is enabled, unless INTX_DISABLE is set.

In addition to the Tigon3 cases, I added quirk entries for the
SB700/800 SATA chips and the IXP SB400 USB controllers.  And as
a result of the latter we can remove several AMD full-chipset
MSI disable quirks which are no longer necessary.

Signed-off-by: David S. Miller <davem@davemloft.net>

Re: [PATCH 0/5]: Resolve MSI vs. INTX_DISABLE quirks, V2.

[Jeff Garzik]

David Miller wrote:
> Ok, I've respun the patches including all of the feedback I've
> obtained.  Again, it's at:
> 
> 	kernel.org:/pub/scm/linux/kernel/git/davem/msiquirk-2.6.git
> 
> Greg, I think this stuff is ready to go so if you would pull
> them in I would really appreciate it.
> 
> These changes clean up the handling of the common quirk wherein
> setting INTX_DISABLE will mistakedly disable MSI generation for some
> devices.
> 
> For devices without that problem, we want to keep the pci_intx() calls
> in drivers/pci/msi.c because those help protect against devices with
> the opposite problem.  Such devices always generate INTX interrupts
> even when MSI is enabled, unless INTX_DISABLE is set.
> 
> In addition to the Tigon3 cases, I added quirk entries for the
> SB700/800 SATA chips and the IXP SB400 USB controllers.  And as
> a result of the latter we can remove several AMD full-chipset
> MSI disable quirks which are no longer necessary.
> 
> Signed-off-by: David S. Miller <davem@davemloft.net>

[corrected subject line s/4/5/.  the actual patches are OK]

Acked-by: Jeff Garzik <jgarzik@redhat.com>

Questions about SATA hotplug in linux 2.6

[Shane Huang]

Greetings:

I have some questions about SATA HDD/ODD hotplug support in linux.
1. If users unplug one SATA HDD(no-root partition) or SATA ODD when
the system is running, then plug it back to the same SATA port,
Should the system and SATA HDD/ODD still work well?

2. How about users plug the SATA HDD/ODD in a different SATA port?
Should it still work?

These questions come up when our QA test our SB700 SATA drivers,
but I don't know the SATA hotplug support in linux 2.6.
Is there any guy who can give some official confirmation? :-)


Thanks
Best Regards

Shane

Re: Questions about SATA hotplug in linux 2.6

[Jeff Garzik]

Shane Huang wrote:
> 1. If users unplug one SATA HDD(no-root partition) or SATA ODD when
> the system is running, then plug it back to the same SATA port,
> Should the system and SATA HDD/ODD still work well?

Yes.

> 2. How about users plug the SATA HDD/ODD in a different SATA port?
> Should it still work?

Yes.

For all hotplug-aware libata drivers, you should be able to unplug a 
SATA device _while_ it is actively reading or writing data, with no ill 
effects to the kernel.

You might lose cached and in-flight data of course, and userspace 
applications may or may not handle the disappearance of their underlying 
filesystem with grace and aplomb :)

But device hotplug should be reliable from a kernel standpoint [assuming 
driver support].


> These questions come up when our QA test our SB700 SATA drivers,
> but I don't know the SATA hotplug support in linux 2.6.
> Is there any guy who can give some official confirmation? :-)

The main thing of note with regards to hotplug is that the associated 
device (/dev/sdb, /dev/scd0, etc.) may change between plug and unplug. 
For example, if you unplug a SATA HDD then plug it back in, the user 
might see /dev/sdb disappear, and /dev/sdd appear -- even if it is the 
exact same HDD, on the exact same port.

	Jeff

Re: Questions about SATA hotplug in linux 2.6

[Tejun Heo]

Jeff Garzik wrote:
> Shane Huang wrote:
>> 1. If users unplug one SATA HDD(no-root partition) or SATA ODD when
>> the system is running, then plug it back to the same SATA port,
>> Should the system and SATA HDD/ODD still work well?
> 
> Yes.

To add a bit, libata hotplug has grace time of at least 15secs.  If the
same device is plugged out and then plugged in in that time, libata
considers that the device and/or connection has suffered transient
failure and assumes it's the same device and there's no modification to
its content.

This means that if you disconnect a harddrive, write to it and then
connect it back in the grace period corruption will occur.  It will be
fun to have some sort of competition to actually do this.  :-)

>> These questions come up when our QA test our SB700 SATA drivers,
>> but I don't know the SATA hotplug support in linux 2.6.
>> Is there any guy who can give some official confirmation? :-)
> 
> The main thing of note with regards to hotplug is that the associated
> device (/dev/sdb, /dev/scd0, etc.) may change between plug and unplug.
> For example, if you unplug a SATA HDD then plug it back in, the user
> might see /dev/sdb disappear, and /dev/sdd appear -- even if it is the
> exact same HDD, on the exact same port.

Yeah, using LABEL and/or UUID is a good idea.  In the future, it will be
nice to have persistent block device name as netdevices do.

-- 
tejun

RE: Questions about SATA hotplug in linux 2.6

[Shane Huang]

Hi Jeff  and  Tejun:


I want to continue this discussion with some questions:

> From: Tejun Heo wrote:
> Jeff Garzik wrote:
> > Shane Huang wrote:
> >> 1. If users unplug one SATA HDD(no-root partition) or SATA ODD when
> >> the system is running, then plug it back to the same SATA port,
> >> Should the system and SATA HDD/ODD still work well?
> >
> > Yes.
> 
> To add a bit, libata hotplug has grace time of at least 15secs.  If
the
> same device is plugged out and then plugged in in that time, libata
> considers that the device and/or connection has suffered transient
> failure and assumes it's the same device and there's no modification
to
> its content.
> 
> This means that if you disconnect a harddrive, write to it and then
> connect it back in the grace period corruption will occur.  It will be
> fun to have some sort of competition to actually do this.  :-)
> 
> >> These questions come up when our QA test our SB700 SATA drivers,
> >> but I don't know the SATA hotplug support in linux 2.6.
> >> Is there any guy who can give some official confirmation? :-)
> >
> > The main thing of note with regards to hotplug is that the
associated
> > device (/dev/sdb, /dev/scd0, etc.) may change between plug and
unplug.
> > For example, if you unplug a SATA HDD then plug it back in, the user
> > might see /dev/sdb disappear, and /dev/sdd appear -- even if it is
the
> > exact same HDD, on the exact same port.
> 
> Yeah, using LABEL and/or UUID is a good idea.  In the future, it will
be
> nice to have persistent block device name as netdevices do.


When I disconnect SATA ODD and plug it back to the same SATA port after
several seconds, it can still work well. But if I plug it to a different
SATA port, it will NOT able to work any more. I will attach the log
messages at the end of this mail, please check them.

My Env:
SB700 + RS780, openSUSE10.3 i386.

I also find the same symptom on Intel E210882 (ICH5) under RedHat
RHEL4U5.
That's to say failure of SATA hotplug to different ports also exist on
some Intel platforms.

Do you guys think it's normal? It not, how to make SATA hotplug work on
different SATA port? Should it be supported by BIOS or hardware?


====== plug SATA ODD to the original port, still can work =========
Dec 18 15:06:29 linux-i276 kernel: ata3: exception Emask 0x10 SAct 0x0
SErr 0x90200 action 0xe frozen
Dec 18 15:06:29 linux-i276 kernel: ata3: irq_stat 0x00400000 , <PHY RDY
changed> 
Dec 18 15:06:29 linux-i276 kernel: ata3: hard resetting link
Dec 18 15:06:30 linux-i276 kernel: ata3: SATA link down (SStatus 0
SControl 300)
Dec 18 15:06:30 linux-i276 kernel: ata3: failed to recover some devices,
retrying in 5 secs
Dec 18 15:06:35 linux-i276 kernel: ata3: hard resetting link
Dec 18 15:06:35 linux-i276 kernel: ata3: SATA link down (SStatus 0
SControl 300)
Dec 18 15:06:35 linux-i276 kernel: ata3: limiting SATA link speed to 1.5
Gbps
Dec 18 15:06:35 linux-i276 kernel: ata3.00: limiting speed to
UDMA/33:PIO3
Dec 18 15:06:35 linux-i276 kernel: ata3: failed to recover some devices,
retrying in 5 secs
Dec 18 15:06:40 linux-i276 kernel: ata3: hard resetting link
Dec 18 15:06:41 linux-i276 kernel: ata3: SATA link up 1.5 Gbps (SStatus
113 SControl 310)
Dec 18 15:06:41 linux-i276 kernel: ata3.00: configured for UDMA/33
Dec 18 15:06:41 linux-i276 kernel: ata3: EH pending after completion,
repeating EH (cnt=4)
Dec 18 15:06:41 linux-i276 kernel: ata3: exception Emask 0x10 SAct 0x0
SErr 0x40c0000 action 0xb
Dec 18 15:06:41 linux-i276 kernel: ata3: irq_stat 0x00000040 ,
<connection status changed> 
Dec 18 15:06:42 linux-i276 kernel: ata3: soft resetting link
Dec 18 15:06:42 linux-i276 kernel: ata3: SATA link up 1.5 Gbps (SStatus
113 SControl 310)
Dec 18 15:06:42 linux-i276 kernel: ata3.00: configured for UDMA/33
Dec 18 15:06:42 linux-i276 kernel: ata3: EH complete

====== plug SATA ODD to a different SATA port, can NOT work =========
Dec 18 15:09:10 linux-i276 kernel: ata3: exception Emask 0x10 SAct 0x0
SErr 0x90200 action 0xe frozen
Dec 18 15:09:10 linux-i276 kernel: ata3: irq_stat 0x00400000 , <PHY RDY
changed> 
Dec 18 15:09:10 linux-i276 kernel: ata3: hard resetting link
Dec 18 15:09:10 linux-i276 kernel: ata3: SATA link down (SStatus 0
SControl 310)
Dec 18 15:09:10 linux-i276 kernel: ata3: failed to recover some devices,
retrying in 5 secs
Dec 18 15:09:15 linux-i276 kernel: ata3: hard resetting link
Dec 18 15:09:16 linux-i276 kernel: ata3: SATA link down (SStatus 0
SControl 310)
Dec 18 15:09:16 linux-i276 kernel: ata3.00: limiting speed to
UDMA/33:PIO2
Dec 18 15:09:16 linux-i276 kernel: ata3: failed to recover some devices,
retrying in 5 secs
Dec 18 15:09:21 linux-i276 kernel: ata3: hard resetting link
Dec 18 15:09:21 linux-i276 kernel: ata3: SATA link down (SStatus 0
SControl 310)
Dec 18 15:09:21 linux-i276 kernel: ata3.00: disabled
Dec 18 15:09:21 linux-i276 kernel: ata3: EH complete
Dec 18 15:09:21 linux-i276 kernel: ata3.00: detaching (SCSI 2:0:0:0)
Dec 18 15:09:22 linux-i276 kernel: scsi 2:0:0:0: rejecting I/O to dead
device





Thanks
Shane

Re: Questions about SATA hotplug in linux 2.6

[Tejun Heo]

Shane Huang wrote:
> Hi Jeff  and  Tejun:
> 
> 
> I want to continue this discussion with some questions:
> 
>> From: Tejun Heo wrote:
>> Jeff Garzik wrote:
>>> Shane Huang wrote:
>>>> 1. If users unplug one SATA HDD(no-root partition) or SATA ODD when
>>>> the system is running, then plug it back to the same SATA port,
>>>> Should the system and SATA HDD/ODD still work well?
>>> Yes.
>> To add a bit, libata hotplug has grace time of at least 15secs.  If
> the
>> same device is plugged out and then plugged in in that time, libata
>> considers that the device and/or connection has suffered transient
>> failure and assumes it's the same device and there's no modification
> to
>> its content.
>>
>> This means that if you disconnect a harddrive, write to it and then
>> connect it back in the grace period corruption will occur.  It will be
>> fun to have some sort of competition to actually do this.  :-)
>>
>>>> These questions come up when our QA test our SB700 SATA drivers,
>>>> but I don't know the SATA hotplug support in linux 2.6.
>>>> Is there any guy who can give some official confirmation? :-)
>>> The main thing of note with regards to hotplug is that the
> associated
>>> device (/dev/sdb, /dev/scd0, etc.) may change between plug and
> unplug.
>>> For example, if you unplug a SATA HDD then plug it back in, the user
>>> might see /dev/sdb disappear, and /dev/sdd appear -- even if it is
> the
>>> exact same HDD, on the exact same port.
>> Yeah, using LABEL and/or UUID is a good idea.  In the future, it will
> be
>> nice to have persistent block device name as netdevices do.
> 
> 
> When I disconnect SATA ODD and plug it back to the same SATA port after
> several seconds, it can still work well. But if I plug it to a different
> SATA port, it will NOT able to work any more. I will attach the log
> messages at the end of this mail, please check them.
> 
> My Env:
> SB700 + RS780, openSUSE10.3 i386.
> 
> I also find the same symptom on Intel E210882 (ICH5) under RedHat
> RHEL4U5.
> That's to say failure of SATA hotplug to different ports also exist on
> some Intel platforms.
> 
> Do you guys think it's normal? It not, how to make SATA hotplug work on
> different SATA port? Should it be supported by BIOS or hardware?

If you connect it to a different port, the original device will die and
new device will appear.  That's the expected behavior.  In the log, I
only see ata3.00 is dying.  Isn't there any log from different port?

-- 
tejun

RE: Questions about SATA hotplug in linux 2.6

[Shane Huang]

Hi Tejun:


> > Do you guys think it's normal? It not, how to make SATA hotplug work
on
> > different SATA port? Should it be supported by BIOS or hardware?
> 
> If you connect it to a different port, the original device will die
and
> new device will appear.  That's the expected behavior.  In the log, I
> only see ata3.00 is dying.  Isn't there any log from different port?

There is no other log from the different port such as the enablement of
ata2,
it's strange. I forgot to say that this case appear when the "OnChip
SATA Type"
is "Native IDE"(SATA device ID is 4390) in BIOS.

But when I set "OnChip SATA type" into "AHCI" mode(SATA device ID 4391),
the hotplug can work, and the device name will be changed from "scd0" to
"scd1"
during the hotplug. The log messages are attached at the end of this
mail.

But I need the reasonable explanation to the failure under "Native IDE"
mode.

Thanks
Shane

====== plug SATA ODD to a different SATA port under AHCI mode, can work
========
Dec 18 18:40:07 linux-i276 kernel: ata3: exception Emask 0x10 SAct 0x0
SErr 0x90200 action 0xe frozen
Dec 18 18:40:07 linux-i276 kernel: ata3: irq_stat 0x00400000 , <PHY RDY
changed> 
Dec 18 18:40:07 linux-i276 kernel: ata3: hard resetting link
Dec 18 18:40:08 linux-i276 kernel: ata3: SATA link down (SStatus 0
SControl 310)
Dec 18 18:40:08 linux-i276 kernel: ata3: failed to recover some devices,
retrying in 5 secs
Dec 18 18:40:13 linux-i276 kernel: ata3: hard resetting link
Dec 18 18:40:13 linux-i276 kernel: ata3: SATA link down (SStatus 0
SControl 310)
Dec 18 18:40:13 linux-i276 kernel: ata3.00: limiting speed to
UDMA/33:PIO2
Dec 18 18:40:13 linux-i276 kernel: ata3: failed to recover some devices,
retrying in 5 secs
Dec 18 18:40:15 linux-i276 kernel: ata2: exception Emask 0x10 SAct 0x0
SErr 0x40c0000 action 0xa frozen
Dec 18 18:40:15 linux-i276 kernel: ata2: irq_stat 0x00000040 ,
<connection status changed> 
Dec 18 18:40:16 linux-i276 kernel: ata2: soft resetting link
Dec 18 18:40:16 linux-i276 kernel: ata2: SATA link up 1.5 Gbps (SStatus
113 SControl 300)
Dec 18 18:40:16 linux-i276 kernel: ata2.00: ATAPI: TSSTcorp CDDVDW
TS-H653B, CM01, max UDMA/33
Dec 18 18:40:16 linux-i276 kernel: ata2.00: configured for UDMA/33
Dec 18 18:40:16 linux-i276 kernel: ata2: EH complete
Dec 18 18:40:16 linux-i276 kernel: scsi 1:0:0:0: CD-ROM
TSSTcorp CDDVDW TS-H653B  CM01 PQ: 0 ANSI: 5
Dec 18 18:40:16 linux-i276 kernel: sr1: scsi3-mmc drive: 40x/40x writer
dvd-ram cd/rw xa/form2 cdda tray
Dec 18 18:40:16 linux-i276 kernel: sr 1:0:0:0: Attached scsi CD-ROM sr1
Dec 18 18:40:16 linux-i276 kernel: sr 1:0:0:0: Attached scsi generic sg2
type 5
Dec 18 18:40:18 linux-i276 kernel: ata3: hard resetting link
Dec 18 18:40:19 linux-i276 kernel: ata3: SATA link down (SStatus 0
SControl 310)
Dec 18 18:40:19 linux-i276 kernel: ata3.00: disabled
Dec 18 18:40:19 linux-i276 kernel: ata3: EH complete
Dec 18 18:40:19 linux-i276 kernel: ata3.00: detaching (SCSI 2:0:0:0)
Dec 18 18:40:19 linux-i276 kernel: scsi 2:0:0:0: rejecting I/O to dead
device
Dec 18 18:40:43 linux-i276 syslog-ng[2291]: last message repeated 6
times

Re: Questions about SATA hotplug in linux 2.6

[Tejun Heo]

Hello,

Shane Huang wrote:
>>> Do you guys think it's normal? It not, how to make SATA hotplug work
> on
>>> different SATA port? Should it be supported by BIOS or hardware?
>> If you connect it to a different port, the original device will die
> and
>> new device will appear.  That's the expected behavior.  In the log, I
>> only see ata3.00 is dying.  Isn't there any log from different port?
> 
> There is no other log from the different port such as the enablement of
> ata2,
> it's strange. I forgot to say that this case appear when the "OnChip
> SATA Type"
> is "Native IDE"(SATA device ID is 4390) in BIOS.
> 
> But when I set "OnChip SATA type" into "AHCI" mode(SATA device ID 4391),
> the hotplug can work, and the device name will be changed from "scd0" to
> "scd1"
> during the hotplug. The log messages are attached at the end of this
> mail.

That's strange.  I guess we're forgetting something when forcing the
controller into AHCI mode.  What happens if you manually issue re-scan
by doing "echo - - - > /sys/class/scsi_host/hostN/scan" where hostN is
the SCSI host for the ATA port you moved the drive?

Also, after driver is loaded, can you please post the results of "lspci
-nnvvvxxx" with BIOS mode set to IDE and AHCI?

Thanks.

-- 
tejun

RE: Questions about SATA hotplug in linux 2.6

[Shane Huang]

Hi Tejun:


> -----Original Message-----
> From: Tejun Heo [mailto:htejun@gmail.com]
> >
> > But when I set "OnChip SATA type" into "AHCI" mode(SATA device ID
4391),
> > the hotplug can work, and the device name will be changed from
"scd0" to
> > "scd1"
> > during the hotplug. The log messages are attached at the end of this
> > mail.
> 
> That's strange.  I guess we're forgetting something when forcing the
> controller into AHCI mode.  

Yes, it's strange. This issue also exists on RedHat RHEL5.1 and RHEL4.6


> What happens if you manually issue re-scan
> by doing "echo - - - > /sys/class/scsi_host/hostN/scan" where hostN is
> the SCSI host for the ATA port you moved the drive?

"echo" helps nothing in this issue, the /dev/scd1 still can not appear,
Here is the log message when do "echo", ata2 is the new SATA port
connected
to SATA HDD after hotplug under native IDE mode:
================================================
Dec 21 00:38:00 linux-d8vg kernel: ata2: soft resetting link
Dec 21 00:38:00 linux-d8vg kernel: ata2: SATA link down (SStatus 0
SControl 300)
Dec 21 00:38:00 linux-d8vg kernel: ata2: EH complete


> Also, after driver is loaded, can you please post the results of
"lspci
> -nnvvvxxx" with BIOS mode set to IDE and AHCI?

There are too much messages, I only keep the SATA controller as below:
========= Native IDE mode =======
00:11.0 SATA controller [Class 0106]: ATI Technologies Inc SB700 SATA
Controller [IDE mode] [1002:4390] (prog-if 01 [AHCI 1.0])
	Subsystem: ATI Technologies Inc SB700 SATA Controller [IDE mode]
[1002:4390]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 64, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 22
	Region 0: I/O ports at d000 [size=8]
	Region 1: I/O ports at c000 [size=4]
	Region 2: I/O ports at b000 [size=8]
	Region 3: I/O ports at a000 [size=4]
	Region 4: I/O ports at 9000 [size=16]
	Region 5: Memory at fe8ff800 (32-bit, non-prefetchable)
[size=1K]
	Capabilities: [60] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
Queue=0/2 Enable-
		Address: 0000000000000000  Data: 0000
	Capabilities: [70] #12 [0010]
00: 02 10 90 43 07 01 30 02 00 01 06 01 10 40 00 00
10: 01 d0 00 00 01 c0 00 00 01 b0 00 00 01 a0 00 00
20: 01 90 00 00 00 f8 8f fe 00 00 00 00 02 10 90 43
30: 00 00 00 00 60 00 00 00 00 00 00 00 0b 01 00 00
40: 10 00 3a 20 01 00 10 00 00 00 00 01 00 00 00 00
50: 05 70 84 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 01 50 22 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 12 00 10 00 0f 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 06 00 00 2c 16 80 b4 01 16 80 b4 01
90: 16 80 b4 01 16 80 b4 01 16 80 b4 01 16 80 b4 01
a0: 7a a0 7a a0 7a a0 7a a0 7a a0 7a a0 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00
e0: 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

========= AHCI mode =======
00:11.0 SATA controller [Class 0106]: ATI Technologies Inc SB700 SATA
Controller [AHCI mode] [1002:4391] (prog-if 01 [AHCI 1.0])
	Subsystem: ATI Technologies Inc SB700 SATA Controller [AHCI
mode] [1002:4391]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 64, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 22
	Region 0: I/O ports at d000 [size=8]
	Region 1: I/O ports at c000 [size=4]
	Region 2: I/O ports at b000 [size=8]
	Region 3: I/O ports at a000 [size=4]
	Region 4: I/O ports at 9000 [size=16]
	Region 5: Memory at fe8ff800 (32-bit, non-prefetchable)
[size=1K]
	Capabilities: [60] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
Queue=0/2 Enable-
		Address: 0000000000000000  Data: 0000
	Capabilities: [70] #12 [0010]
00: 02 10 91 43 07 01 30 02 00 01 06 01 10 40 00 00
10: 01 d0 00 00 01 c0 00 00 01 b0 00 00 01 a0 00 00
20: 01 90 00 00 00 f8 8f fe 00 00 00 00 02 10 91 43
30: 00 00 00 00 60 00 00 00 00 00 00 00 0b 01 00 00
40: 10 00 00 20 01 00 10 00 00 00 00 01 00 00 00 00
50: 05 70 84 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 01 50 22 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 12 00 10 00 0f 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 06 00 00 2c 16 80 b4 01 16 80 b4 01
90: 16 80 b4 01 16 80 b4 01 16 80 b4 01 16 80 b4 01
a0: 7a a0 7a a0 7a a0 7a a0 7a a0 7a a0 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00
e0: 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00



Thanks
Shane

RE: Questions about SATA hotplug in linux 2.6

[Shane Huang]

Hi Tejun:


> > That's strange.  I guess we're forgetting something when forcing the
> > controller into AHCI mode.
> 
> Yes, it's strange. This issue also exists on RedHat RHEL5.1 and
RHEL4.6
> 
> > What happens if you manually issue re-scan
> > by doing "echo - - - > /sys/class/scsi_host/hostN/scan" where hostN
is
> > the SCSI host for the ATA port you moved the drive?
> 
> "echo" helps nothing in this issue, the /dev/scd1 still can not
appear,
> Here is the log message when do "echo", ata2 is the new SATA port
connected
> to SATA HDD after hotplug under native IDE mode:

It seems that this issue has been fixed by our up to date BIOS.
I will give you more information after further confirmation when
necessary.


Thanks
Shane

Re: Questions about SATA hotplug in linux 2.6

[Tejun Heo]

Hello, Shane.

Shane Huang wrote:
>>> That's strange.  I guess we're forgetting something when forcing the
>>> controller into AHCI mode.
>> Yes, it's strange. This issue also exists on RedHat RHEL5.1 and
> RHEL4.6
>>> What happens if you manually issue re-scan
>>> by doing "echo - - - > /sys/class/scsi_host/hostN/scan" where hostN
> is
>>> the SCSI host for the ATA port you moved the drive?
>> "echo" helps nothing in this issue, the /dev/scd1 still can not
> appear,
>> Here is the log message when do "echo", ata2 is the new SATA port
> connected
>> to SATA HDD after hotplug under native IDE mode:
> 
> It seems that this issue has been fixed by our up to date BIOS.
> I will give you more information after further confirmation when
> necessary.

Great, thanks.

-- 
tejun

Re: [PATCH 0/4]: Resolve MSI vs. INTX_DISABLE quirks, V2.

[Greg KH]

On Thu, Oct 25, 2007 at 01:14:45AM -0700, David Miller wrote:
> 
> Ok, I've respun the patches including all of the feedback I've
> obtained.  Again, it's at:
> 
> 	kernel.org:/pub/scm/linux/kernel/git/davem/msiquirk-2.6.git
> 
> Greg, I think this stuff is ready to go so if you would pull
> them in I would really appreciate it.

These all look great to me, and I've pulled them into my trees.

Thanks a lot for doing this work.

I think they should go to Linus before 2.6.24 is out, any objection from
anyone else with this?

thanks,

greg k-h

Re: [PATCH 0/4]: Resolve MSI vs. INTX_DISABLE quirks, V2.

[David Miller]

From: Greg KH <greg@kroah.com>
Date: Thu, 25 Oct 2007 11:32:48 -0700

> These all look great to me, and I've pulled them into my trees.
> 
> Thanks a lot for doing this work.

Thanks for integrating.